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

["Pascal Rapicault" <pascal_rapicault@xxxxxxxx>]

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

    I totaly understand your concern here but it's the same problem
everywhere
    in the platform... what happens if people badly behaves when they run
through
    a resource delta, or listen any specific plugin: we are in trouble.

    To minimise the drama for the deactivation, I would point out three
things:
        - if we have 5000 plugins, it is very unlikely that all of them will
care for changes,
        and it is very likely that they will do nothing in the notification
method. We need to
        remember the hierarchical topology of plugins.

        - the deactivation and/or disablement should not occur very
frequently
        and will probably be done on user request so the user could handle a
relatively
        long operation

        - we can provide a basic infrastructure to allow plugin writers to
easily and efficiently
        find out if they care about a given delta.


> My preference would be to send deltas to just the parties that are
> registered to listen for events on that registry item.
    Also this model is interesting for the optimization it provides, but I
think it can not
    fits in every case because we can not make the assumption that a plugin
will correctly
    collect all its instances (removing all its listeners, removing markers,
etc.).
    For example the resource plugin needs to know about every plugin leaving
so it can
    do extra cleanup for the plugin that is being deactivated (see
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
Plugins/deactivatingPlugins.html). If we wanted to do the notification only
    for registrered plugin, it will mean that either the resource plugin
would have to "automatically" register
    itself to listen to all the modification of a plugin that directly or
indirectly requires it,
    or that plugin writer who requires resource register its plugin
correctly.

    To me, the advantage of the global notification mechanism is that is it
simple, which
    is important.


Regards,

    PaScaL