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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

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.

Jeff

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b626eu$89v$1@xxxxxxxxxxxxxxxx
> 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
>