[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.equinox] Re: Separating concerns...
Pascal Rapicault wrote: 
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.


This is kind of arguing that since we have problems elsewhere that it is okay to design problems in here.


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.


If they are not likely to do anything with the event, why are we sending it to them? I would argue that it is actually less work for the concerned listeners to simply register their interest than for ALL developers to recieve, parse and then ignore/react to ALL events.


- 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


A week or two ago, the rationals for deactivation included passively freeing up resources, but apparently that has been dropped? :-)

What about the case where plugin 'A' programmatically wants plugin 'B1' deactivated so that it can replace it (dynamically) with plugin 'B2' (for example to change an implementation of an API for which there can only be one resident provider)? 'A' may be the only dependent on B1/B2 in the entire planet, yet we are going to notify _every_ registry listener that it did so? If this bogs down, this isn't necessarily based on User request and it certainly isn't the fault of the 'A' or 'B1/B2' plugins.


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


Why not instead provide a basic api that allows a plugin writer to easily register to recieve ALL delta events if they care about all of them? That seems like a much more efficient way to distribute the msg.


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.


So in the model I described, the resource plugin would simply register to listen to ALL deltas. This pathological resource plugin case does not justify the reverse: that all other registry listeners must necessarily register to recieve all deltas.

One additional concern is that with a 'broadcast to all' strategy is that there is no ordering of notification along with potentially long latencies. It seems to me this increases the likelyhood of unintended deadlock scenarios because one event might trigger multiple events. With only the concerned parties being notified, and waiting on their handling of it before processing (broadcasting) the next event, I would think there is a more natural implicit handling of dependencies in the notification order.

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


I disagree strongly that it is simpler to the extent that it outweighs the performance and reliability disadvantages I'm pointing out. The difference in the 'simplicity' of the two models can be summed up as providing either:

public void registerListener(listener)

or

public void registerListener(key,listener)

and in the latter case being able to specify a key that says "send me all events".

Having all listeners recieve all events, even if they are _supposed_ to ignore 99% of them, is abdicating platform responsibility and giving it to third parties over whom the platform has no control.


Mel



Regards,

    PaScaL