Re: Changes to Events API

On Wed, Aug 07, 2002 at 03:54:34PM +0200, Martin Matula wrote:
> from the discussions that I saw at some external mailing lists and from 
> the discussions I had with the people here at Sun that intend to use the 
>   MDR it showed up that what would be a good thing to have is a 
> possibility to listen to events on objects' containers (composites). 

I like this. On the other hand is there any implementation
(e.g. performance) reason to restrict this to references from
component to composite. The composition relation is introduced by the
meta-modeler and might not be the right thing for the applications on
the model level.

> Now the question is, how the listeners should register for the events 
> from containers. I would like to add method addListener(..., boolean 
> includeComponents), however this would be applicable only for 
> registering listeners on RefObjects. Should there be a special 
> RefObjectEventSource for RefObjects? Any suggestions are welcome.
> Martin

In your case I would add a flag in the bitmask instead of introducing
a new method.

But following my more general idea I would do something like the
following (although I do not know how it performs):

Additional method on association proxies which makes links on this proxy
permeable for events:

  /**
   *  Makes links of this association proxy permeable for events
   *  of type <code>eventMask</code>. (Probably this method should
   *  be only called when there is a reference in the given direction ?!)
   *
   * @param direction if <code>true</code> links are made permeable in
   *     the direction from first to second end, if <code>false</code>
   *     they are made permeable in the other direction.
   * @param eventMask determines the type of events the links are made
   *     permeable for
   * @param permeableMask A mask which is associated with the event
   *    when it goes through a link; when an event goes through several
   *    links, the masks are combined via <code>||</code>. Before being
   *    transported through any link a link has a permeable mask with all
   *    bits set to 1.
   */
  MDRAssociationChangeSource.makePermeable(boolean direction, int eventMask,
                                           int permeableMask);

Additional method on instances which allow to register for event gone
through links.

  /**
   *  ..
   *  @param permeableMask the listener receives only those events where
   *          the permeable mask of the event, if combined via
   *          <code>||</code> with the permeable mask of the listener, results
   *          in a value different from <code>0</code>.
   */
  MDRInstanceChangeSource.addListener(MDRChangeListener listener,
                                      int eventMask, int permeableMask);


The additional permeabeMask bitmask would allow an application to
managed at finite number of different channels, on which events could
be forwarded via links. For each association proxy the method
makePermeable(..) would determine for which channels events are
forwarded. For each instance proxy the method
addListener(..,permeableMask) would determine, on which channels the
listener listens.


Implementation: 
  
1) Map RefClass => Collection of (permeableMask, Index) modified by calls to
                   makePermeable

2) Instance event => look up RefClass and retrieve 
        Collection(permeableMask,Index) => iterate through this collection,
        for each entry wrap event with permeableMask and forward it to the
        objects accessible via the index

Pro: 

- extremely flexible and powerful

Contra: 
  
- (maybe) performance, but actually I do not think so: If it's not used
  it's only one more check of the form `map == null' per instance event.
  If it's used, it should simplify the client application significantly,
  hence the performance cost on the repository side will be balanced
  by the performance savings on the client side.
- if several applications will use the repository the bits set by them in
  `permeableMask' will clash, so listeners retrieve events they
  never wanted to have (actually this point is solvable also, but any
  solution makes the interfaces more difficult)
- only a finite number of channels (each solution here probably would affect
  performance more severly)
- does not allow forwarding of event from attribute components to composite
  (the solution is not to use attribute components !)  


-- 
Holger Krug
[email protected]