Home » Eclipse Projects » Equinox » classes fordynamic plugin events
| classes fordynamic plugin events [message #15527] |
Wed, 26 March 2003 19:35  |
Eclipse User |
|
|
|
This will be a crude attempt to try to get the ball rolling towards
developing the interfaces necessary to support lifecycle events
resulting from a dynamic component model. I'm not going to try to get
the exact details exactly right here because I don't yet claim to have
thought of everything (that's scheduled for a few weeks from now).
Anyway, the way I see it, if we have a dynamic plugin model, we need to
identify what the sources of change events are going to be and who the
interested parties will be.
First off, it seems to me that the IPluginRegistry interface needs to be
extended or replaced with an interface that allows mutation of the registry.
public interface DynamicPluginRegistry extends IPluginRegistry{
...
public void setExtensionPoint(String path, String name,
IExtensionPoint expoint);
...
public void addRegistryEventListener(RegistryListener l, String path);
}
(Note - I am philosophically opposed to prefixing interface names with
"I" but will yield to the majority.)
An abstract, default implementation of this would have the requisit
'fireRegistryEvent()' method, of course.
The Registry implementation would register listeners for events on a
specific path ('id') in the registry. Thus avoiding excess event
broadcasting.
Next, this new PluginRegistry is a definite potential source of events
resulting from a plugin dynamically being loaded/unloaded. Thus, it
seems logical that we need some classes like:
public class RegistryEvent {
public RegistryEvent(String regPath, Class regType, Object oldVal,
Object newVal){
...
};
public String getPath(){...}
public Class getType(){...}
public Object getOldValue(){...}
public Object getNewValue(){...}
}
public interface RegistryListener{
public void addEvent(RegistryEvent e);
public void removeEvent(RegistryEvent e);
public void changeEvent(RegistryEvent e);
}
The simplistic tack now says that one could extend the abstract Plugin
class to build something like:
public class AbstractDynamicPlugin implements RegistryListener {
...
}
Alternatively, one could consume the RegistryListener interface into an
intermediate DynamicPlugin interface. Existing plugins could be
retrofit to be dynamic by implementing the DynamicPlugin interface.
The ambitious tack says that if we think we can shim all existing
plugins into the dynamic world, then we could modify Plugin to implement
the interface with default listener methods. Might want to add an
attribute to the interface that signifies participation, though, with a
default value of "false" that the child must override.
Next on the agenda, we jump upstream and try to figure out where the
changes to the PluginRegistry are coming from. I'm still learning the
lay of the land, but it seems to me they are coming from any changes to
the PlatformConfiguration, sincej (according to the javaodocs) the
IPlatformConfiguration "Represents the runtime configuration used by the
Eclipse platform. Any configuration changes do not take effect until
next startup of the Eclipse platform".
The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
responsible for finding all the features that need to be loaded which
then lead to the plugins that need to be loaded. I say beast because
this is one heck of a 'BLOB' class. This class has about 2031 fields,
43 million methods and a half-dozen internal classes (*shudder*). Man,
does it SCREAM for refactoring. But ignoring that for the moment, the
important thing is that it seems to me that if we are going to support
dynamic components, then this beasty will have to give up on that 2nd
sentence in the javadoc comment I quoted. If we dynamically add a
component to the platform, then clearly the PlatformConfiguration must
be able to change.
So we need to create a similar source/listener model for
PlatformConfigurationEvents that will communicate changes in the
PlatformConfiguration to the PluginRegistry. The PluginRegistry in turn
needs to implement a PlatformConfigurationListener interface.
I haven't thought through all the details there, yet. I'll try to
evolve this more tomorrow.
I'd appreciate thoughts and feedback. Unless I get negative feedback on
this, I'm going to flesh out the details and code these concepts up for
submission. That would give us something to start chewing on.
Cheers,
Mel
|
|
|
| Re: classes fordynamic plugin events [message #15657 is a reply to message #15527] |
Thu, 27 March 2003 11:05  |
| Eclipse User |
|
|
|
Mel,
All that is great because you go in the same direction than the one Jeff and
I proposed
(see the website), although your API slightly differs from what we have.
Last week I commited an initial API and implementation of a notification
mechanism for "dynamic plugins". The API has been designed to stay
consistent
with the eclipse philosophy, so I copied the notification model of the
Resource plugin:
There is an event, that carries a plugin registry delta.
We still need to understand whether or not all plugins should get notified,
there are
real test cases where plugins that are being required needs to know about
event
on plugins requiring them.
We haven't thought to the modification of the PlatformConfiguration yet, but
as you
mentionned it is important to understand what are the implication of
dynamicity on this
component. It could be great if you could contribute your discoveries on the
website.
Since you already thought about a dynamic API, could you please comment the
questions
that are on the website, and that also in the code (TODO tag).
Thanx,
PaScaL
|
|
|
| Re: classes fordynamic plugin events [message #16621 is a reply to message #15527] |
Fri, 28 March 2003 12:36 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Mel,
One a specific point... the configuration... well, things are not that
clear. See below...
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b5tgsj$nau$1@rogue.oti.com...
> Next on the agenda, we jump upstream and try to figure out where the
> changes to the PluginRegistry are coming from. I'm still learning the
> lay of the land, but it seems to me they are coming from any changes to
> the PlatformConfiguration, sincej (according to the javaodocs) the
> IPlatformConfiguration "Represents the runtime configuration used by the
> Eclipse platform. Any configuration changes do not take effect until
> next startup of the Eclipse platform".
>
> The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
> responsible for finding all the features that need to be loaded which
> then lead to the plugins that need to be loaded. I say beast because
> this is one heck of a 'BLOB' class. This class has about 2031 fields,
> 43 million methods and a half-dozen internal classes (*shudder*). Man,
> does it SCREAM for refactoring.
Could not agree more... but actually, this is the least of our problem...
Our main concern is that Eclipse has so many ways to bootstrap...
and obtain its plugins or its features... as directories... as URLs,
or as a combination... I am still quite fighting with understanding boot
and all its bootstrap cases...
The most interesting aspect though is that boot, through
PlatformConfiguration, knows about features... and shows a somewhat
clean interface to what the configuration is... but then it vanishes at
the runtime plugin level... which takes a list of URLs for its plugin
path...
The entire plugin registry is oblivious to features... and they show back
up in the update manager.
So one of the first decision before anything else is to decide
if features are first-class runtime concepts or not. Given how
the plugin registry is now sandwitched between boot and update
plugins... Does it make sense to have the plugin registry ignore
features?
I would also argue that boot could be much cleaner if it would
always boot through a configuration file... as opposed to the
multitude of cases it handles now. Beside historical reasons,
I don't see why we should keep all those special cases around?
Also, I would argue that up from the boot plugin... Equinox
should use that PlatformConfiguration... this would apply to
runtime and update plugins at the very least. I haven't been able
to convince myself that update manager uses PlatformConfiguration
to installs plugins... Can someone confirms it ?
Best regards,
|
|
|
| Separating concerns... [message #16657 is a reply to message #15527] |
Fri, 28 March 2003 13:11 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Mel,
Onto another aspect....
I would like us to separate concerns a bit... it seems that we
are too much focus on plugins... what I mean by that is that
we want event notifications about plugins lifecycles... mostly
because we load and unload plugins... but actually, plugin
developers know nothing about plugins... in most cases...
From most plugin developers' perspective (pun intended :-),
plugins do not really exist... they deal with extensions and
extension points through the registry... or directly with
Java classes (like SWT or Xerces)... they don't know
about plugins most of the time, and I believe it should
remain that way.
As you can guess...I feel strongly about this :-)
Hence, I would argue that the first level of notifications
should be solely regarding extensions and extension points...
not plugins. From a programming model standpoint, I
don't see why plugin event-cycle notification is necessary.
Of course, from an administrative stand point, this is
different and we may have another level of notification
for those who care about plugins and their life cycle.
But it seems that we are talking different things and
I feel that we should keep them separate.
So, along those lines, as an extension point provider,
I am interested to know if new extensions are available
for my extension point or if some are disappearing.
This is enough to support plugin loading/unloading as
well as dynamic registration of extensions and extension points.
So as a first step, we just need to extend the registry to
load or unload plugins and to have notifications about
extensions and extension points.
Once we have the basic functionality (load/unload of
a plugin with the corresponding notifications about
extensions and extension points)... we can move
to allow adding/revoking individual extensions and
extension poins... In other words, allowing a programmatic
interface to the plugin registry for extensions and extension
points.
The interface chances are more profound there... since
IPluginRegistry and IExtension are read only and we are
asking to allow creation... But this should not be too
difficult.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b5tgsj$nau$1@rogue.oti.com...
> This will be a crude attempt to try to get the ball rolling towards
> developing the interfaces necessary to support lifecycle events
> resulting from a dynamic component model. I'm not going to try to get
> the exact details exactly right here because I don't yet claim to have
> thought of everything (that's scheduled for a few weeks from now).
>
> Anyway, the way I see it, if we have a dynamic plugin model, we need to
> identify what the sources of change events are going to be and who the
> interested parties will be.
>
> First off, it seems to me that the IPluginRegistry interface needs to be
> extended or replaced with an interface that allows mutation of the
registry.
>
> public interface DynamicPluginRegistry extends IPluginRegistry{
> ...
> public void setExtensionPoint(String path, String name,
> IExtensionPoint expoint);
> ...
> public void addRegistryEventListener(RegistryListener l, String path);
> }
>
> (Note - I am philosophically opposed to prefixing interface names with
> "I" but will yield to the majority.)
>
> An abstract, default implementation of this would have the requisit
> 'fireRegistryEvent()' method, of course.
>
> The Registry implementation would register listeners for events on a
> specific path ('id') in the registry. Thus avoiding excess event
> broadcasting.
>
> Next, this new PluginRegistry is a definite potential source of events
> resulting from a plugin dynamically being loaded/unloaded. Thus, it
> seems logical that we need some classes like:
>
> public class RegistryEvent {
> public RegistryEvent(String regPath, Class regType, Object oldVal,
> Object newVal){
> ...
> };
> public String getPath(){...}
> public Class getType(){...}
> public Object getOldValue(){...}
> public Object getNewValue(){...}
> }
>
> public interface RegistryListener{
> public void addEvent(RegistryEvent e);
> public void removeEvent(RegistryEvent e);
> public void changeEvent(RegistryEvent e);
> }
>
> The simplistic tack now says that one could extend the abstract Plugin
> class to build something like:
>
> public class AbstractDynamicPlugin implements RegistryListener {
> ...
> }
>
> Alternatively, one could consume the RegistryListener interface into an
> intermediate DynamicPlugin interface. Existing plugins could be
> retrofit to be dynamic by implementing the DynamicPlugin interface.
>
> The ambitious tack says that if we think we can shim all existing
> plugins into the dynamic world, then we could modify Plugin to implement
> the interface with default listener methods. Might want to add an
> attribute to the interface that signifies participation, though, with a
> default value of "false" that the child must override.
>
> Next on the agenda, we jump upstream and try to figure out where the
> changes to the PluginRegistry are coming from. I'm still learning the
> lay of the land, but it seems to me they are coming from any changes to
> the PlatformConfiguration, sincej (according to the javaodocs) the
> IPlatformConfiguration "Represents the runtime configuration used by the
> Eclipse platform. Any configuration changes do not take effect until
> next startup of the Eclipse platform".
>
> The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
> responsible for finding all the features that need to be loaded which
> then lead to the plugins that need to be loaded. I say beast because
> this is one heck of a 'BLOB' class. This class has about 2031 fields,
> 43 million methods and a half-dozen internal classes (*shudder*). Man,
> does it SCREAM for refactoring. But ignoring that for the moment, the
> important thing is that it seems to me that if we are going to support
> dynamic components, then this beasty will have to give up on that 2nd
> sentence in the javadoc comment I quoted. If we dynamically add a
> component to the platform, then clearly the PlatformConfiguration must
> be able to change.
>
> So we need to create a similar source/listener model for
> PlatformConfigurationEvents that will communicate changes in the
> PlatformConfiguration to the PluginRegistry. The PluginRegistry in turn
> needs to implement a PlatformConfigurationListener interface.
>
> I haven't thought through all the details there, yet. I'll try to
> evolve this more tomorrow.
>
> I'd appreciate thoughts and feedback. Unless I get negative feedback on
> this, I'm going to flesh out the details and code these concepts up for
> submission. That would give us something to start chewing on.
>
> Cheers,
>
> Mel
>
|
|
|
| Separating concerns (part II) [message #16691 is a reply to message #15527] |
Fri, 28 March 2003 13:27 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
In a previous posting, I described that we would be
better off if we kept a good separation of concerns
between those interested about extension points and
extensions and those interested about plugin life cycles
per se...
As Pascal mentioned, we have a firs draft based on
deltas. I agree with the very basic information about
plugins being added, removed, and changed.
For deactivated, I would also agree for monitoring
purposes.
For disabled... I didn't know we had a disabled state...
so what is the difference between disabled and unloaded ?
While I am on the subject, I also don't quite understand
the primed state... Does it mean that the class loader
is present but the plugin has not executed any code yet?
If so, this is very analog to the OSGi RESOLVED versus
ACTIVE states for a bundle (remember a bundle is equivalent
to a library plugin).
I am questioning that the delta should include extension
information... I don't have a strong opinion either way...
but I would like to hear the rationale if we have two
levels of notification, one for extension-related events
and one for plugin life-cycle events.
For simplicity, wouldn't it be more interesting to separate
again. Have events for plugin life-cycle and administrative
extension-related events...
I can hear already the clamor about too many events...
I disagree in advance... :-)
We have the events to extension providers.
We have the events to extension providers.
Those are key and all plugins will receive them.
For backward compatibility, they may ignore them...
for an optimization, we may send them to only plugins
declaring themselves dynamic-aware...
Then, we are likely to have only one administrative plugin,
the update manager today...
It will listen to plugin events and all extension-related
events, if and only if it has an interest in those...
Today, it is not obvious to me that the update manager
will even care about extension-related events...
In general, plugins needing to know about plugin life-cycle
events AND extension-related events should be pretty rare...
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b5tgsj$nau$1@rogue.oti.com...
> This will be a crude attempt to try to get the ball rolling towards
> developing the interfaces necessary to support lifecycle events
> resulting from a dynamic component model. I'm not going to try to get
> the exact details exactly right here because I don't yet claim to have
> thought of everything (that's scheduled for a few weeks from now).
>
> Anyway, the way I see it, if we have a dynamic plugin model, we need to
> identify what the sources of change events are going to be and who the
> interested parties will be.
>
> First off, it seems to me that the IPluginRegistry interface needs to be
> extended or replaced with an interface that allows mutation of the
registry.
>
> public interface DynamicPluginRegistry extends IPluginRegistry{
> ...
> public void setExtensionPoint(String path, String name,
> IExtensionPoint expoint);
> ...
> public void addRegistryEventListener(RegistryListener l, String path);
> }
>
> (Note - I am philosophically opposed to prefixing interface names with
> "I" but will yield to the majority.)
>
> An abstract, default implementation of this would have the requisit
> 'fireRegistryEvent()' method, of course.
>
> The Registry implementation would register listeners for events on a
> specific path ('id') in the registry. Thus avoiding excess event
> broadcasting.
>
> Next, this new PluginRegistry is a definite potential source of events
> resulting from a plugin dynamically being loaded/unloaded. Thus, it
> seems logical that we need some classes like:
>
> public class RegistryEvent {
> public RegistryEvent(String regPath, Class regType, Object oldVal,
> Object newVal){
> ...
> };
> public String getPath(){...}
> public Class getType(){...}
> public Object getOldValue(){...}
> public Object getNewValue(){...}
> }
>
> public interface RegistryListener{
> public void addEvent(RegistryEvent e);
> public void removeEvent(RegistryEvent e);
> public void changeEvent(RegistryEvent e);
> }
>
> The simplistic tack now says that one could extend the abstract Plugin
> class to build something like:
>
> public class AbstractDynamicPlugin implements RegistryListener {
> ...
> }
>
> Alternatively, one could consume the RegistryListener interface into an
> intermediate DynamicPlugin interface. Existing plugins could be
> retrofit to be dynamic by implementing the DynamicPlugin interface.
>
> The ambitious tack says that if we think we can shim all existing
> plugins into the dynamic world, then we could modify Plugin to implement
> the interface with default listener methods. Might want to add an
> attribute to the interface that signifies participation, though, with a
> default value of "false" that the child must override.
>
> Next on the agenda, we jump upstream and try to figure out where the
> changes to the PluginRegistry are coming from. I'm still learning the
> lay of the land, but it seems to me they are coming from any changes to
> the PlatformConfiguration, sincej (according to the javaodocs) the
> IPlatformConfiguration "Represents the runtime configuration used by the
> Eclipse platform. Any configuration changes do not take effect until
> next startup of the Eclipse platform".
>
> The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
> responsible for finding all the features that need to be loaded which
> then lead to the plugins that need to be loaded. I say beast because
> this is one heck of a 'BLOB' class. This class has about 2031 fields,
> 43 million methods and a half-dozen internal classes (*shudder*). Man,
> does it SCREAM for refactoring. But ignoring that for the moment, the
> important thing is that it seems to me that if we are going to support
> dynamic components, then this beasty will have to give up on that 2nd
> sentence in the javadoc comment I quoted. If we dynamically add a
> component to the platform, then clearly the PlatformConfiguration must
> be able to change.
>
> So we need to create a similar source/listener model for
> PlatformConfigurationEvents that will communicate changes in the
> PlatformConfiguration to the PluginRegistry. The PluginRegistry in turn
> needs to implement a PlatformConfigurationListener interface.
>
> I haven't thought through all the details there, yet. I'll try to
> evolve this more tomorrow.
>
> I'd appreciate thoughts and feedback. Unless I get negative feedback on
> this, I'm going to flesh out the details and code these concepts up for
> submission. That would give us something to start chewing on.
>
> Cheers,
>
> Mel
>
|
|
|
| Re: Separating concerns... [message #16706 is a reply to message #16657] |
Fri, 28 March 2003 14:09 |
| Eclipse User |
|
|
|
Olivier Gruber wrote:
>
> I would like us to separate concerns a bit... it seems that we
> are too much focus on plugins... what I mean by that is that
> we want event notifications about plugins lifecycles... mostly
> because we load and unload plugins... but actually, plugin
> developers know nothing about plugins... in most cases...
>
> From most plugin developers' perspective (pun intended :-),
> plugins do not really exist... they deal with extensions and
> extension points through the registry... or directly with
> Java classes (like SWT or Xerces)... they don't know
> about plugins most of the time, and I believe it should
> remain that way.
>
This is a good point. I thought I made that separation by defining
'RegistryListener' independent of plugins. Thus any class could become
a RegistryListener simply by extending the interface. In fact I was
thinking that it might be desirable behavior that, when resolving
extension points and extensions of, that the two parties be implicitly
checked for instanceof RegistryListener and automatically registered for
events on that registry path.
That shouldn't disallow others for registering to listen, of course.
> So, along those lines, as an extension point provider,
> I am interested to know if new extensions are available
> for my extension point or if some are disappearing.
> This is enough to support plugin loading/unloading as
> well as dynamic registration of extensions and extension points.
Well, there is another area that needs to looked at. Consider that even
if you don't use an extension point, you might be using a reference to a
class exposed through <runtime><export> on the one side and then
<requires> on other. The code that is using an exported class needs to
somehow be told that it is going to be unloaded and that it should
release it's reference and perhaps wait on another event to reaquire.
So the model here might be that in order to <require> a dynamic plugin
the dependent code must in turn provide a designated listener class that
listens for the appropriate load/unload events.
For backward compatibility, if no listener is designated, we could treat
this as a 'lock' that prevents unloading.
Thoughts?
Mel
|
|
|
| Re: Separating concerns... [message #16719 is a reply to message #16706] |
Fri, 28 March 2003 15:05 |
| Eclipse User |
|
|
|
After I wrote the comments below, I saw that Olivier has posted similar
comments in greater detail on this topic at the web site:
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamicPlugins/deactivatingPlugins.html
For those following this thread.
- mel
Mel Martinez wrote:
> Olivier Gruber wrote:
>
>>
>> I would like us to separate concerns a bit... it seems that we
>> are too much focus on plugins... what I mean by that is that
>> we want event notifications about plugins lifecycles... mostly
>> because we load and unload plugins... but actually, plugin
>> developers know nothing about plugins... in most cases...
>>
>> From most plugin developers' perspective (pun intended :-),
>> plugins do not really exist... they deal with extensions and
>> extension points through the registry... or directly with
>> Java classes (like SWT or Xerces)... they don't know
>> about plugins most of the time, and I believe it should
>> remain that way.
>>
>
> This is a good point. I thought I made that separation by defining
> 'RegistryListener' independent of plugins. Thus any class could become
> a RegistryListener simply by extending the interface. In fact I was
> thinking that it might be desirable behavior that, when resolving
> extension points and extensions of, that the two parties be implicitly
> checked for instanceof RegistryListener and automatically registered for
> events on that registry path.
>
> That shouldn't disallow others for registering to listen, of course.
>
>> So, along those lines, as an extension point provider,
>> I am interested to know if new extensions are available
>> for my extension point or if some are disappearing.
>> This is enough to support plugin loading/unloading as
>> well as dynamic registration of extensions and extension points.
>
>
> Well, there is another area that needs to looked at. Consider that even
> if you don't use an extension point, you might be using a reference to a
> class exposed through <runtime><export> on the one side and then
> <requires> on other. The code that is using an exported class needs to
> somehow be told that it is going to be unloaded and that it should
> release it's reference and perhaps wait on another event to reaquire.
>
> So the model here might be that in order to <require> a dynamic plugin
> the dependent code must in turn provide a designated listener class that
> listens for the appropriate load/unload events.
>
> For backward compatibility, if no listener is designated, we could treat
> this as a 'lock' that prevents unloading.
>
> Thoughts?
>
> Mel
>
|
|
|
| Re: Separating concerns... [message #17616 is a reply to message #16719] |
Mon, 31 March 2003 10:35 |
| Eclipse User |
|
|
|
This page has been moved to
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
Plugins/classloadersAndInstances.html
PaScaL
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b629ou$at0$1@rogue.oti.com...
> After I wrote the comments below, I saw that Olivier has posted similar
> comments in greater detail on this topic at the web site:
>
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
Plugins/deactivatingPlugins.html
>
> For those following this thread.
>
> - mel
>
> Mel Martinez wrote:
> > Olivier Gruber wrote:
> >
> >>
> >> I would like us to separate concerns a bit... it seems that we
> >> are too much focus on plugins... what I mean by that is that
> >> we want event notifications about plugins lifecycles... mostly
> >> because we load and unload plugins... but actually, plugin
> >> developers know nothing about plugins... in most cases...
> >>
> >> From most plugin developers' perspective (pun intended :-),
> >> plugins do not really exist... they deal with extensions and
> >> extension points through the registry... or directly with
> >> Java classes (like SWT or Xerces)... they don't know
> >> about plugins most of the time, and I believe it should
> >> remain that way.
> >>
> >
> > This is a good point. I thought I made that separation by defining
> > 'RegistryListener' independent of plugins. Thus any class could become
> > a RegistryListener simply by extending the interface. In fact I was
> > thinking that it might be desirable behavior that, when resolving
> > extension points and extensions of, that the two parties be implicitly
> > checked for instanceof RegistryListener and automatically registered for
> > events on that registry path.
> >
> > That shouldn't disallow others for registering to listen, of course.
> >
> >> So, along those lines, as an extension point provider,
> >> I am interested to know if new extensions are available
> >> for my extension point or if some are disappearing.
> >> This is enough to support plugin loading/unloading as
> >> well as dynamic registration of extensions and extension points.
> >
> >
> > Well, there is another area that needs to looked at. Consider that even
> > if you don't use an extension point, you might be using a reference to a
> > class exposed through <runtime><export> on the one side and then
> > <requires> on other. The code that is using an exported class needs to
> > somehow be told that it is going to be unloaded and that it should
> > release it's reference and perhaps wait on another event to reaquire.
> >
> > So the model here might be that in order to <require> a dynamic plugin
> > the dependent code must in turn provide a designated listener class that
> > listens for the appropriate load/unload events.
> >
> > For backward compatibility, if no listener is designated, we could treat
> > this as a 'lock' that prevents unloading.
> >
> > Thoughts?
> >
> > Mel
> >
>
|
|
|
| Re: Separating concerns... [message #17731 is a reply to message #16706] |
Mon, 31 March 2003 14:54 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
see
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-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.
Jeff
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b626eu$89v$1@rogue.oti.com...
> Olivier Gruber wrote:
> >
> > I would like us to separate concerns a bit... it seems that we
> > are too much focus on plugins... what I mean by that is that
> > we want event notifications about plugins lifecycles... mostly
> > because we load and unload plugins... but actually, plugin
> > developers know nothing about plugins... in most cases...
> >
> > From most plugin developers' perspective (pun intended :-),
> > plugins do not really exist... they deal with extensions and
> > extension points through the registry... or directly with
> > Java classes (like SWT or Xerces)... they don't know
> > about plugins most of the time, and I believe it should
> > remain that way.
> >
>
> This is a good point. I thought I made that separation by defining
> 'RegistryListener' independent of plugins. Thus any class could become
> a RegistryListener simply by extending the interface. In fact I was
> thinking that it might be desirable behavior that, when resolving
> extension points and extensions of, that the two parties be implicitly
> checked for instanceof RegistryListener and automatically registered for
> events on that registry path.
>
> That shouldn't disallow others for registering to listen, of course.
>
> > So, along those lines, as an extension point provider,
> > I am interested to know if new extensions are available
> > for my extension point or if some are disappearing.
> > This is enough to support plugin loading/unloading as
> > well as dynamic registration of extensions and extension points.
>
> Well, there is another area that needs to looked at. Consider that even
> if you don't use an extension point, you might be using a reference to a
> class exposed through <runtime><export> on the one side and then
> <requires> on other. The code that is using an exported class needs to
> somehow be told that it is going to be unloaded and that it should
> release it's reference and perhaps wait on another event to reaquire.
>
> So the model here might be that in order to <require> a dynamic plugin
> the dependent code must in turn provide a designated listener class that
> listens for the appropriate load/unload events.
>
> For backward compatibility, if no listener is designated, we could treat
> this as a 'lock' that prevents unloading.
>
> Thoughts?
>
> Mel
>
|
|
|
| Re: Separating concerns (part II) [message #17748 is a reply to message #16691] |
Mon, 31 March 2003 15:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b623ui$65c$1@rogue.oti.com...
> For disabled... I didn't know we had a disabled state...
> so what is the difference between disabled and unloaded ?
No such thing as unloaded. deactivated, disabled, uninstalled.
deactivated = no classloader but still in the registry. Could be activated
via normal mechanism
disabled = deactivated + can NOT be reactivated. Extensions retracted.
Effectively uninstalled but still there
uninstalled = disabled + removed from disk/configuratoin. Eclipse does not
know about it.
> While I am on the subject, I also don't quite understand
> the primed state... Does it mean that the class loader
> is present but the plugin has not executed any code yet?
> If so, this is very analog to the OSGi RESOLVED versus
> ACTIVE states for a bundle (remember a bundle is equivalent
> to a library plugin).
That's the point. Resolved seems like an interesting state. Eclipse may do
well to have such a thing.
Note that the "primed" state is just an idea. I would not focus too heavily
on that yet.
> I am questioning that the delta should include extension
> information... I don't have a strong opinion either way...
> but I would like to hear the rationale if we have two
> levels of notification, one for extension-related events
> and one for plugin life-cycle events.
>
> For simplicity, wouldn't it be more interesting to separate
> again. Have events for plugin life-cycle and administrative
> extension-related events...
>
> I can hear already the clamor about too many events...
> I disagree in advance... :-)
>
> We have the events to extension providers.
> We have the events to extension providers.
> Those are key and all plugins will receive them.
> For backward compatibility, they may ignore them...
> for an optimization, we may send them to only plugins
> declaring themselves dynamic-aware...
>
> Then, we are likely to have only one administrative plugin,
> the update manager today...
> It will listen to plugin events and all extension-related
> events, if and only if it has an interest in those...
> Today, it is not obvious to me that the update manager
> will even care about extension-related events...
>
> In general, plugins needing to know about plugin life-cycle
> events AND extension-related events should be pretty rare...
The key point to me is that extensions and extension points are tied to
plugins. You cannot have the former without the latter. Plugins (and thus
extensions and extension points) are managed in a plugin registry. The
deltas we are talking about are plugin registry deltas. Adding an extension
is a change to the registry. There are other ways in which the registry can
change. The delta mechanism captures these various possibilities in a
relatively simple and consistent way.
Jeff
|
|
| |
| Re: classes fordynamic plugin events [message #18496 is a reply to message #16621] |
Mon, 31 March 2003 16:53 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Yes, this area is confusing (features/configurations/plugins...). Basically
features are collections of plugins. They are interesting to the user as
well as the product developer/deployer in that they allow for abstraction.
I don't need to know about all 328 plugins in product A, I just need to know
that its root feature is FeatureA. So product managers create features and
users install features. This is powerful.
At runtime we are interested in what code to run and what extensions go into
which extension points. These are plugin notions. Features help to define
the scope of plugins to consider while building the registry but beyond
that, contribute nothing to the runtime picture.
This is why you see some areas which talk about feature and some which do
not. Think of it like JARs in Java systems. Users (generally)
download/install/manage JARs. The VM init code takes JARs from the
classpath and populates classloaders. The runtime however does not care
about any of this. I just needs the bytes for the classes.
The current implementation is more complicated than needed/desired.
However, there is an underlying thrust that is important (IMHO). Features
are not a runtime concept. They are used by the PlatformConfiguration to
figure out which plugins are relevant but after that list has been computed,
the runtime proper takes the list and starts.
Having said that, there does seem to be dynamic plugins work to be done in
the PlatformConfiguration area.
Jeff
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b620ub$3b2$1@rogue.oti.com...
> Hi Mel,
>
> One a specific point... the configuration... well, things are not that
> clear. See below...
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:b5tgsj$nau$1@rogue.oti.com...
> > Next on the agenda, we jump upstream and try to figure out where the
> > changes to the PluginRegistry are coming from. I'm still learning the
> > lay of the land, but it seems to me they are coming from any changes to
> > the PlatformConfiguration, sincej (according to the javaodocs) the
> > IPlatformConfiguration "Represents the runtime configuration used by the
> > Eclipse platform. Any configuration changes do not take effect until
> > next startup of the Eclipse platform".
> >
> > The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
> > responsible for finding all the features that need to be loaded which
> > then lead to the plugins that need to be loaded. I say beast because
> > this is one heck of a 'BLOB' class. This class has about 2031 fields,
> > 43 million methods and a half-dozen internal classes (*shudder*). Man,
> > does it SCREAM for refactoring.
>
> Could not agree more... but actually, this is the least of our problem...
> Our main concern is that Eclipse has so many ways to bootstrap...
> and obtain its plugins or its features... as directories... as URLs,
> or as a combination... I am still quite fighting with understanding boot
> and all its bootstrap cases...
>
> The most interesting aspect though is that boot, through
> PlatformConfiguration, knows about features... and shows a somewhat
> clean interface to what the configuration is... but then it vanishes at
> the runtime plugin level... which takes a list of URLs for its plugin
> path...
> The entire plugin registry is oblivious to features... and they show back
> up in the update manager.
>
> So one of the first decision before anything else is to decide
> if features are first-class runtime concepts or not. Given how
> the plugin registry is now sandwitched between boot and update
> plugins... Does it make sense to have the plugin registry ignore
> features?
>
> I would also argue that boot could be much cleaner if it would
> always boot through a configuration file... as opposed to the
> multitude of cases it handles now. Beside historical reasons,
> I don't see why we should keep all those special cases around?
>
> Also, I would argue that up from the boot plugin... Equinox
> should use that PlatformConfiguration... this would apply to
> runtime and update plugins at the very least. I haven't been able
> to convince myself that update manager uses PlatformConfiguration
> to installs plugins... Can someone confirms it ?
>
> Best regards,
>
>
|
|
| |
| Re: Separating concerns... [message #18514 is a reply to message #18505] |
Mon, 31 March 2003 21:12 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
> 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~/equi nox-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
|
|
| |
| Re: Separating concerns... [message #19463 is a reply to message #18514] |
Wed, 02 April 2003 13:29 |
| Eclipse User |
|
|
|
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~/equi nox-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
>
>
|
|
| |
| Re: Separating concerns... [message #21725 is a reply to message #20575] |
Tue, 08 April 2003 22:30 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
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@us.ibm.com> wrote in message
news:b6sqea$rdm$1@rogue.oti.com...
> Jeff McAffer wrote:
> > "Mel Martinez" <melm@us.ibm.com> wrote in message
> > news:b6ae1j$5sm$1@rogue.oti.com...
> >
> >
> >>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.
>
>
|
|
|
| Re: Separating concerns... [message #21901 is a reply to message #21725] |
Wed, 09 April 2003 12:34 |
| Eclipse User |
|
|
|
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@us.ibm.com> wrote in message
> news:b6sqea$rdm$1@rogue.oti.com...
>
>>Jeff McAffer wrote:
>>
>>>"Mel Martinez" <melm@us.ibm.com> wrote in message
>>>news:b6ae1j$5sm$1@rogue.oti.com...
>>>
>>>
>>>
>>>>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.
>>
>>
>
>
>
|
|
|
| Re: Separating concerns... [message #21946 is a reply to message #21725] |
Wed, 09 April 2003 12:49 |
| Eclipse User |
|
|
|
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.
>
The difference here is that the events parse and the potential #
listeners for a given 'class' of GUI events is typically from a bounded
set. A button event handler only has a few states to parse when dealing
with a button event' and thus it's "filter" will be overhead on only a
few calls compared to the scenario where it needed to filter on all GUI
events. By partitioning mouse events from, say, a window event, we
reduce both the work involved by the listener's filter and also the
number of potential listeners whose filters will get invoked.
So yes, it is a trade-off on where you draw your lines to make
distinctions, and I agree that when you can't you might as well let the
listener do it's own filtering. And some filtering can only be done
dynamically, at event time. Still good design should try to partition
the event types in some manner to reduce both the number of listeners
involved for each event notification as well as the amount of work each
listener is responsible for.
Mel
|
|
|
| Re: Separating concerns... [message #22035 is a reply to message #21901] |
Wed, 09 April 2003 14:55 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
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@us.ibm.com> wrote in message
news:b71hmk$1pd$1@rogue.oti.com...
> 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@us.ibm.com> wrote in message
> > news:b6sqea$rdm$1@rogue.oti.com...
> >
> >>Jeff McAffer wrote:
> >>
> >>>"Mel Martinez" <melm@us.ibm.com> wrote in message
> >>>news:b6ae1j$5sm$1@rogue.oti.com...
> >>>
> >>>
> >>>
> >>>>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.
> >>
> >>
> >
> >
> >
>
|
|
|
Goto Forum:
Current Time: Sun Jun 08 13:22:29 EDT 2025
Powered by FUDForum. Page generated in 0.08414 seconds |
Home