Re: Does anybody want to replace base handler ?

Hi Holger,

Holger Krug wrote:
> 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.

Nobody said Tomas could not implement the events the same way he would 
in case of non-hierarchical listeners puting isOfType checks on 
listeners to packages/repository. I guess the overhead compared to the 
approach using bitmasks would be very minimal if any.

>>I would like to see the implementation of the API
> 
> 
> Comes soons (at latest tomorrow morning).

Cool.

>>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.

For the interactive case that you are focused on I guess that preChange 
events are not needed and thus the listeners are called only once. In 
this case checks inside of listeners are running on a background thread 
however checks inside of MDR are blocking other threads from working 
with it (it is still inside the transaction).

>>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.

I don't see why this would be a good thing to do.

>>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 ?

I need to see the implementation. I don't see why they are needed by 
EventNotifier. The reason I don't like them is their name. It is not 
obvious from the names what the difference is between EVENTMASK_BY and 
EVENTMASK_ON events is. I would even think that their meaning is 
opposite. I.e. "BY" events are fired *by* the object (object is the 
source), "ON" events are fired *on* object (object is either the source 
or source's package/etc.). It is confusing.
Regards,
Martin