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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b6ae1j$5sm$1@xxxxxxxxxxxxxxxx
> Jeff McAffer wrote:
> > see
> >
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
> > Plugins/registryDelta.html
> >
> > This details the kind of thing one would see when the registry changes.
The
> > API class does not capture all of this.
> >
> > I don't see that there is much in having a mechanism specifically for
> > extensions and extension points.  By telling people the whole picture
they
> > can batch changes, understand the context better and in general do a
better
> > job of handling the changes.  Of course, if they are truly only
interested
> > in particular kinds of changes they can just ignore all others.
> >
>
> There are two things here:
>
> 1) the granularity of the event object.  I have no great problem if it
> contains a delta for the registry as a whole (unless that starts to
> become a large thing to calculate), although I wonder at the value for
> the out-of-context information for a given listener when the listener
> could always just interrogate the registry to get the state of the
> larger context.

The cost should not be large.  The delta is not calculated so much as
tracked.  That is, changes to extensions, extension points etc are in fact
changes to the registry.  All we have to do is remember them.  As for out of
context info, Pascal points out correctly that listeners generally have  to
know their context of interest and short circuit as fast as possible.

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

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

Jeff