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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Mel,

In an earlier message you said:
    "Could you explain or give an example of what you mean here?"
I was fulfilling that request.  The resource model is a usecase where the
simple approach you describe is disappointing.  My suspicion is that the
registry situation is similar though not quite as complex.

Rather than us going back and forth on this, why not implement what you
propose?  At least spec the API.  That way we can all better understand
precisely what is being said and see how the various usecases/situations
would be implemented/handled.

Makes sense?

Jeff

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b71hmk$1pd$1@xxxxxxxxxxxxxxxx
> Well, it seems I _was_ missing something, because I thought we were
> talking about notification of modifications to the plugin registry, not
> to the resources model (which I don't yet fully grok and will not
> comment on).    With the registry, it is fairly straightforward to
> identify the parties of interest on a given registry ID.  This does not
> rely on a filtering action at notification time, but rather simply
> maintaining preregistered listener lists for each id.
>
> I fully concede that it is possible that such pre-registering may not be
> possible for something like the resource system, but even there I'm not
> so sure.  You could possibly use a double-entry scheme.  Each resource
> should have a URL which could point to it's own listener list.  Also
> maintain a separate list of listeners registering with wild-cards.
> Registering a listener means adding him to the latter list plus the list
> of every matching specific URL.  Adding a new potential event source
> means scanning the list of wild-card list for matches and adding those
> listeners to the new source's specific listener list.  Removing either
> is fairly straightforward.  When an event happens, you notify only those
> listeners in the specific resource's list.  The result is notification
> just to the interested parties without requiring event-time filtering.
>
> I'll allow that I haven't looked at the eclipse resource model closely
> yet so maybe this is just wishful thinking, but it seems pretty
> straightforward.
>
> Mel
>
>
>
> Jeff McAffer wrote:
> > 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.
> >>
> >>
> >
> >
> >
>