| Re: plugins on top of osgi [message #28099] |
Tue, 08 July 2003 22:45  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:befh6l$ol0$1@eclipse.org...
> In our new world, we try to get rid of all plugin related class, which is
> fine for me.
>
> However Olivier seems to think that we would need a descriptor to talk
about
> the informations that are specific to a plugin.
>
> So my question:
> So far have you encountered such a need.
Below is an email from Olivier. I have taken the liberty of moving it to
the public forum and will respond in a subsequent post... The context is a
discussion on the merits of continuing with the notion of plugins when we
are based on OSGi which supplies a similar concept called bundles. That is,
do we need both concepts? Are they different names for the same thing, ...
=======================
In fact, I believe that
plugins = bundles + extensions/extpt
is an interesting distinction.
The point is that the programming model changes.
Without plugins, bundle programmers only know about packages and services.
No concept whatsoever about extension and extension points.
But when adding extensions/extension points, it changes the programming
model,
rather it extends it... no pun intended.
First, we are introducing a new registry. Second, extensions have their own
life cycle,
their own events, and we are talking about their own activation mechanism if
we don't
do automated activation. This is a lot and I believe it warrants a concept.
It also enforces the understanding that OSGi is usable standalone as well
as with the extra Eclipse container: bringing in a new concept and
corresponding
integration platform.
Also, how is the various APIs looking?
How is the plugin registry API then? Only extensions and extension points?
How are you grouping events? Not by plugin? Are you still considering a
world-wide delta as opposed to have plugins receiving local deltas?
I believe the plugin object needs to receive the delta about its extension
points. I believe the Plugin object is where to attach those delta
management
methods.
Also, how is the administration API on the registry? Is there one?
If there is one, what is it showing? Can I introspect on extensions and
extension points?
How do I know to which bundle they correspond?
How is PDE will surface the two manifests?
How do you enforce the single name space for extension points and plugins if
plugins don't exist? I guess you are doing it at the bundle level in the
resolver.
Correct?
Just a few questions... :-)
Cheers,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
|
|
|
| Re: plugins on top of osgi [message #28137 is a reply to message #28099] |
Tue, 08 July 2003 23:23  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:befvli$4h2$1@eclipse.org...
>
> Below is an email from Olivier. I have taken the liberty of moving it to
> the public forum and will respond in a subsequent post... The context is
a
> discussion on the merits of continuing with the notion of plugins when we
> are based on OSGi which supplies a similar concept called bundles. That
is,
> do we need both concepts? Are they different names for the same thing,
....
>
> =======================
>
> In fact, I believe that
>
> plugins = bundles + extensions/extpt
>
> is an interesting distinction.
>
> The point is that the programming model changes.
> Without plugins, bundle programmers only know about packages and services.
> No concept whatsoever about extension and extension points.
> But when adding extensions/extension points, it changes the programming
> model,
> rather it extends it... no pun intended.
> First, we are introducing a new registry. Second, extensions have their
own
> life cycle,
> their own events, and we are talking about their own activation mechanism
if
> we don't
> do automated activation. This is a lot and I believe it warrants a
concept.
The same things could be said of services. There are bundles which
define/use services and those which don't. The OSGi folks did not
distinguish between the two types. Similarly, there are Eclipse plugins
which define extensions and extension points and those which don't. Plugin
developers don't seem to see any particular value in drawing the
distinction.
The automatic activation story for executable extensions is very much in
line with the proposed declarative services model.
> It also enforces the understanding that OSGi is usable standalone as well
> as with the extra Eclipse container: bringing in a new concept and
> corresponding
> integration platform.
If you don't introduce an "extra container" then there is never any doubt
that OSGi is usable standalone. There is only one component concept,
bundles. That is an OSGi thing and there is some additional
services/infrastructure that Eclipse brings to the table just like any other
set of components.
It would be a bummer if anyone ever had to ask "is X a plugin or a bundle?".
IMHO it would be more apt/clear to say "does X have any extensions/ext pts?"
Question: If I define something which has no extensions/ext pt but uses
say, Eclipse runtime function, is it a bundle or a plugin?
The proposal is to answer that question by saying that everything is a
bundle and some bundles have extensions/ext pt.
> Also, how is the various APIs looking?
>
> How is the plugin registry API then? Only extensions and extension points?
There are no plugins so there is no plugin registry. There is an extensions
registry. I believe you can see the API in the org.eclipse.core.registry
package in the runtime project.
> How are you grouping events? Not by plugin?
By bundle.
> Are you still considering a
> world-wide delta as opposed to have plugins receiving local deltas?
Not quite sure what you mean here but the deltas are broadcast to the
registered listeners. There is room to automatically register certain
people who contribute extensions etc. That is still being worked through.
> I believe the plugin object needs to receive the delta about its extension
> points. I believe the Plugin object is where to attach those delta
> management
> methods.
The deltas should go to listeners. Dictating that those listeners are
plugin objects does not seem to contribute much.
> Also, how is the administration API on the registry? Is there one?
> If there is one, what is it showing? Can I introspect on extensions and
> extension points?
> How do I know to which bundle they correspond?
See the api mentioned above.
> How is PDE will surface the two manifests?
I'm not a UI expert or a PDE guy but there are many examples of editors
showing a model which in real life is stored in more than one file. I don't
see this as a problem.
> How do you enforce the single name space for extension points and plugins
if
> plugins don't exist? I guess you are doing it at the bundle level in the
> resolver.
> Correct?
Plugin == bundle. Just do a text replacement.
To be clear here, we will not be able to drop the term "plugin". It is too
well known/used. Rather it would continue to be used and would be
interchangeable with "bundle". This is simple, clear and easy for people to
understand and accept.
In the end it may be that there are a set of helper classes and files that
we provide/allow which do alot of the common operations/roles here. I see
this as analogous to the OSGi ServiceTracker rather than the grander notion
of plugin.
Jeff
> Just a few questions... :-)
> Cheers,
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04923 seconds
Home