[news.eclipse.technology.equinox] Re: Separating concerns...

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Mel,

I don't think you are missing anything.  Of course directing events to those
most interested can be a good thing. The usecases I refer to is where the
description, maintenance and management of "interest" is not
straightforward.  In the UI case, UI frameworks allow you to listen for
relatively simple events (mouse clicks, key presses, moves, ...).  These are
easily filtered, copied, described and so are easily directed to particular
listeners.

The UI frameworks generally do not allow you to receive notification only
when, for example, the right-shift is down and the click is in the title bar
of a window whose label is...  Rather, you listen for the base events and
then synthesize the rest.  Clearly you will get more notifications than you
want but that is the trade off.

In Eclipse the resources model is another example.  We broadcast resource
change events to all listeners.  We could (and may well) include the ability
for someone to refine their interest to say "only changes involving *.java
files".  If you look at the implementation of this, someone has to do the
filtering.  Having the framework do it is interesting if there is some
performance potential.  In this exact scenario, it is unlikely that any two
listeners have the same filter set (other than "all changes").  So the event
notifier has to run the filters for each listener.  This filtering is
basically what the listener could/would do if we just generically gave it
the event.  There is no performance gain unless we could filter faster.  To
equalize tihs, we expose a generally useful, ultra fast filter mechanism
that they can use.  Same code we would run but more useful.  They get more
flexibility, a simpler model and the same/better performance.

Better performance?!.  Yes.  It is generally not economical for the notifier
to trim the resource deltas to contain only the items of interest to a
particular listener.  This involves lots of copies or other manipulations.
The net is that the event listener is going to have to walk at least a
portion of the dataset to find its items of interest.  So in effect the
filter is run twice.

Summary:  The difference relates to the complexity of the events and the
handling.  If you have simple, discrete events then the approach you suggest
is best.  As the events and event processing/synthesis get more complex, it
gets hard to write a performant, general, flexible notification filtering
mechanism.

In the case at hand (plugin registry delta notification), I would like to
see a spec for the event filter descriptions that would be required.   I
fully agree that directed notification *could* be more efficient but it is
not clear that the complexity cost of the filter spec mechanism is worth it.
Again, you still have to run each listener's filters to figure out if the
event is interesting so the argument is that the notifier could somehow do
this faster than the listener.

Jeff

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b6sqea$rdm$1@xxxxxxxxxxxxxxxx
> Jeff McAffer wrote:
> > "Mel Martinez" <melm@xxxxxxxxxx> wrote in message
> > news:b6ae1j$5sm$1@xxxxxxxxxxxxxxxx
> >
> >
> >>2) the granularity of the messaging.  Are you saying that for every
> >>registry event you would prefer to broadcast that to every listener?
> >>Doesn't that become problematic in the hypothetical 5000 plugin case?
> >>If there are only two or three plugins that are actually affected by an
> >>event, it is really inefficient to make 5000 calls that each have to
> >>examine the delta to see if it is of concern before no-op'ing.  One
> >>badly written plugin could slow up the processing of EVERY event!  Maybe
> >>I'm misunderstanding you here.
> >
> >
> > Yes. but (there has to be one :-) the 5000 plugin case is for 5000
> > *installed* plugins.  Not 5000 *active* plugins.  You only need to
notify
> > active plugins.  Even still processing the changes for 300 active
plugins
> > could be non-trivial.  Plugin writers should follow Pascal's advice and
> > no-op early and the runtime can likely provide mechanisms to help them
do
> > that (as we do in other places in Eclipse).
> >
>
> Why is this preferable to them just not registering to recieve the event
> in the first place?
>
> Isn't this analogous to having every GUI event in an app sent to every
> event handler and requiring each such handler to filter to identify just
> the events it is interested in?  I.E. even if I'm only interested in
> events generated by a particular button, I have to recieve and filter
> all other events:
>
> public class MyButtonHandler{
>   ...
>   theApp.registerForALLEvents(this);
>   ...
>   public void doEvent(Event e){
>    if(isMyButtonEvent(e)){   //<-- I am forced to examine every event
>     ...do stuff
>    }
>   }
> }
>
> I'd have thought it pretty well accepted that it is preferable to
> pre-filter by only registering to recieve those events that one is
> interested in.
>
> public class MyButtonHandler{
>   ...
>   theButton.registerForEvents(this);
> // or theApp.registerForButtonEvents(this);
>   ...
>   public void doEvent(Event e){
>    ...do stuff...
>   }
> }
>
> The former model is well-recognized as not scaling, is more vulnerable
> to bad programmer mistakes (since it asks more of the programmer) and
> since more parties are involved with every event notification more
> susceptable to cyclic dependency problems.  The latter model scales very
> well, asks less of each handler programmer and since fewer participants
> are involved on each notification decreases the chance of cyclic
> dependencies.
>
>
> >
> >>My preference would be to send deltas to just the parties that are
> >>registered to listen for events on that registry item.
> >
> >
> > I actually agree with this but every time we have tried to implement
such a
> > mechanism, it turns out to be more complicated to manage and run both
from a
> > mechanism and user point of view.
> >
>
> Could you explain or give an example of what you mean here?  I'm really
> struggling with trying to understand why you and Pascal are advocating
> this design (notifying all listeners of all events as opposed to just
> notifying those listeners registered to listen for events on particular
> parts of the registry).  I allow that I am missing something, but it is
> not yet obvious to me.
>
>