Re: Does anybody want to replace base handler ?

On Mon, Jul 15, 2002 at 03:28:31PM +0200, Martin Matula wrote:
> I agree the API is nice. It looks a lot like my first MDR API (back 
> before February 5, before I refactored it). But at that time I had also 
> different event sources for assiciation, instance, etc. Then during the 
> February I have refactored and simlified it and during this 
> simplification I also removed the bitmask thing. The only thing that 
> remained was the isOfType method in MDRChangeEvent enabling listeners to 
> filter the events themselves. It seemed to me that this mechanism was 
> sufficient. 

You are probably right for non-interactive use cases. But concerning
interactive apps I cannot agree with you, after having seen Tomas'
code in the MDRExplorer. Tomas was forced to make up his own listener
registration structure on top of MDR.

> I would like to see the implementation of the API

Comes soons (at latest tomorrow morning).

> to see if it is that much more efficient to filter events inside of
> MDR than inside of each listener (I expect that you will need to
> have some "if {} else {}" clauses in the listener even if it will
> use the bitmask).

The advantage of making these checks outside of the listener is, that
a) the listeners are called two times and b) all listeners which apply
are put into a queue. Hence even if I would put all "if"'s also into
the listener (what is not necessary) the additional external check
probably would be more efficient in most case.

> Checking the bitmask on each listener can be reduced by grouping several 
> listeners registered under the same bitmask in some kind of hashmap 
> which would speed things up given that there are many listeners 
> registered under the same bitmask.

I expect that in most cases only a few listeners are registered for
every object (Each `view' typically registers one listener). Hence it
should more performant to iterate over all those listeners than to
make up additional data-structures. Admittedly the best solution would
be to make the data-structure depend on the number and kind of
listeners. Hence I created a new inner class ListenerSet, instances of
which represent all listeners registered for one repository
object. This class contains all the code which possibly should be
further optimized depending on the use cases (numbers of listeners per
object etc.) which are deemed to be the most important. The
optimization could even consist in making ListenerSet an interface and
defining the implementing class by a system property. This would allow
to provide the most optimal solution for every kind of application.

> But in case of EVENTMASK_ALL and EVENTMASK_ON_.. this is no win over
> the previous proposal with no bitmasks. Do you expect to have many
> listeners on bitmasks other than these two?

It heavily depends on the use cases. In complicated interactive
environments you will have *all* kinds of bitmasks you only can
imagine.

> Another thing I am concerned about are the names of the constants. What 
> is the difference between EVENTMASK_ON_... constants in MDRChangeEvent 
> class and EVENTMASK_... constants in subclasses of MDRChangeEvent?

The image in the Javadoc of MDRChangeSource shows to meaning of
EVENTMASK_ON_... . E.g.:

 EVENTMASK_ON_INSTANCE = EVENTMASK_ATTRIBUTE | EVENT_INSTANCE_DELETE;

> I don't think that EVENTMASK_BY_... constants are that useful. 

They aren't quite useful for users, I admit. They are used internally
in the EventNotifier code and were introduced to avoid errors
resulting from future API changes. Otherwise EventNotifier would
depend more heavily on the internals of the event API. So to say:
These constants define part of the interface between EventNotifier and
the event API. The best solution would be to make them public to
EventNotifier, but not to the user, what is not possible in Java. Any
proposal ?

-- 
Holger Krug
[email protected]