This evening, I have completed the implementation of the simple design
of outgoing ``interception'' that Rodrigo Senra, Luiz Eduardo Buzato
and I have agreed upon a while ago. I'm not sure we got to post the
design to the list (sorry if I failed to do it :-(, but here's the
idea:

An Operation now implements interface Message. Whenever a reflective
Object A initiates an Operation on another Object B, the Operation
will be broadcast to A's meta-configuration before B's primary
MetaObject is given the opportunity to handle it.

A's MetaObjects cannot modify the Operation, nor redirect it, but,
being informed about the Operation, they can (somehow) negotiate their
entry in the meta-configuration of the target of the Operation and,
being there, they can easily test whether the Operation was indeed
initiated by their original MetaObject using
Operation.initiatedBy(Object). This does not expose the initiator of
the Operation, which is necessary to preserve the security of the MOP
(*), while still allowing the MO that needs this verification to do
so. This verification also enables the MO to verify, at the time it
receives the Operation as a Message, that it is not being fooled by
some other meta-level Object: it can verify that the Operation has
already being submitted for execution (perform()), and that the Object
it controls, whose reference it receives as the second argument of
handle(Message,Object), is indeed the initiator of the Operation.


For now, Operations initiated from the meta-level, from native code or
using the Java Core Reflection API are regarded as not having an
initiator, but this shouldn't be relied upon, and it can't be
verified, as passing null as the argument to initiatedBy() will get it
to return false anyway.

Comments?


I'd appreciate if people could give this a try before I release
Guaranį 1.8. I've uploaded a patch file that should bring Guaranį 1.7
up to the current state; it's now available at
http://www.ic.unicamp.br/~oliva/snapshots/guarana/guarana-1.7-1.8pre.tar.bz2

The patch file does not contain changes for guarana.jar, since it's a
binary file, so it must be updated by hand. After building the whole
thing, enter kaffe/libraries/extensions/guarana/javalib and run `make
build-classes' to update it.

Please let me know in case you run into any problems.

Enjoy!


(*) otherwise, a component MO might take control over its parent by
setting up a MMO on itself, waiting for its parent to invoke an
operation on it and then obtaining a reference to the initiator from
the operation, so obtaining references to the initiator must not be
allowed.

--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me