Home » Eclipse Projects » Equinox » decisions going forward
| decisions going forward [message #26422] |
Wed, 18 June 2003 21:52  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
A mail message from Olivier Gruber regarding moving forward on the prototype
implementation he has created...
1) Multi-version or not.
The OSGi layer imposes only one version for a bundle. The Eclipse registry
has the possibility of several version for a plugin. It would ne nice if we
could decide upfront where we stand. Given that only plugins without
extensions can be loaded with multiple versions and given that they are now
only bundles, not plugins anymore... could we agree that both layers (OSGi
and Plugin registry) are single-version?
I personally would vote for no-multi version, at both level. I don't like to
see a programming model exposing a multi-version concept for both packages
and services. Note that the scope model allows to have multi-version
across scopes but retain a single-version API.
2) Separate space for plugin names and extension point names.
The current registry is assuming two separate spaces. It could be
constrained to have only one space, but it is visible in the implementation.
I would argue that it is better to allow for the functionality than not.
If we disagree there, we will have to fork about the plugin registry. I
don't want to loose all I did, I will still conduct experiments on that,
from a research perspective.
3) Virtualize install.
In the design, the Eclipse registry partitipates in the two-phase install.
In other words, when installing a plugin, the update manager can introspect
the future state of both the OSGi layer and the Eclipse registry. Again,
this has major impacts on the data structure of the registry.
I personnally argue that it is just better to allow a virtualize registry.
This leaves the ability for update manager to actually have rules on the
matching of extensions and extension points. For example, if there are no
extension points matching the extensions of a plugin, maybe one wants to see
a warning or error during the install.
Again, if we disagree there, we will have to fork about the plugin registry.
I don't want to loose all I did, I will still conduct experiments on that,
from a research perspective.
|
|
|
| Re: decisions going forward [message #26459 is a reply to message #26422] |
Wed, 18 June 2003 22:18  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:bcr51r$s0t$1@rogue.oti.com...
> A mail message from Olivier Gruber regarding moving forward on the
prototype
> implementation he has created...
>
> 1) Multi-version or not.
>
> The OSGi layer imposes only one version for a bundle. The Eclipse registry
> has the possibility of several version for a plugin. It would ne nice if
we
> could decide upfront where we stand. Given that only plugins without
> extensions can be loaded with multiple versions and given that they are
now
> only bundles, not plugins anymore... could we agree that both layers (OSGi
> and Plugin registry) are single-version?
>
Many of the people on the Eclipse team as well as users feel that the
compelling multiple version usecases are real and must continue to be
supported by Eclipse. To some people this as a lot of work to support a few
fringe things like multiple versions of Xerces. It is true we are only
supporting multiple versions of library plugins. Libraries will be
increasingly important as more and more is done with Eclipse. People are
not always going to be starting from nothing and building everything. They
want to get and use as much as they can from others. This covers
Eclipse-based things like GEF and EMF as well as non-Eclipse things line
Xerces, Xalan, JDBC drivers, ... Having multiple versions enables the
integration of independent plugin wads(aka products) into the same Eclipse
runtime.
As a side note, almost all component runtimes that I know of support
multiple versions. DLLs/unix shared libs, .net, Eclipse :-),... I don't
know about things like Avalon. Can anyone out there comment?
> I personally would vote for no-multi version, at both level. I don't like
to
> see a programming model exposing a multi-version concept for both packages
> and services. Note that the scope model allows to have multi-version
> across scopes but retain a single-version API.
I am not sure what you mean here. No one is proposing that a particular
piece of code be exposed to multiple versions of the packages or services it
consumes. The whole point of scopes, requires/provides, whatever is to
allow for multiple versions of packages/bundles to exist in the runtime but
yet have any given consumer see only the version dictated by their scope,
requires list, ...
The only code that would be seeing multiple versions would be the
management/admin code which necessarily needs the global view.
> 2) Separate space for plugin names and extension point names.
>
> The current registry is assuming two separate spaces. It could be
> constrained to have only one space, but it is visible in the
implementation.
> I would argue that it is better to allow for the functionality than not.
>
> If we disagree there, we will have to fork about the plugin registry. I
> don't want to loose all I did, I will still conduct experiments on that,
> from a research perspective.
To date we have not seen any compelling usecases which would take advantage
of this separation. I am not inherently opposed to it but given that
extension points are explicitly defined as the mechanism for plugins
declaring their, well, points of extension, it seems strange to decouple
them.
I understand the merits of having a mechanism which has this sort of
separation but suspect that services can satisfy that demand. In what way
are services insufficient for the usecases you see?
> 3) Virtualize install.
>
> In the design, the Eclipse registry partitipates in the two-phase install.
> In other words, when installing a plugin, the update manager can
introspect
> the future state of both the OSGi layer and the Eclipse registry. Again,
> this has major impacts on the data structure of the registry.
>
> I personnally argue that it is just better to allow a virtualize registry.
> This leaves the ability for update manager to actually have rules on the
> matching of extensions and extension points. For example, if there are no
> extension points matching the extensions of a plugin, maybe one wants to
see
> a warning or error during the install.
>
> Again, if we disagree there, we will have to fork about the plugin
registry.
> I don't want to loose all I did, I will still conduct experiments on that,
> from a research perspective.
What scenarios or usecases are solved by this extra mechanism? It has the
unfortunate effect of tying an otherwise independent layer above the
framework (the registry stuff) into the layer below (bundle resolution).
Meta-statement re forking: Having separate, short-lived, branches of
investigation is good in any project. It is important however that we put
forward a clear vision/statement of the design we are proposing. It would
be unfortunate if the forks you suggest were long-lived and blurred the
Equinox work for us or observers. I suggest that as a group we decide on a
path and focus our efforts in that direction. Private, long-lived forks
should be held locally.
Jeff
|
|
|
| Re: decisions going forward [message #26622 is a reply to message #26459] |
Thu, 19 June 2003 09:31 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
See my detailled comments/answers below.
On you meta-comment:
> Meta-statement re forking: Having separate, short-lived, branches of
> investigation is good in any project. It is important however that we put
> forward a clear vision/statement of the design we are proposing. It would
> be unfortunate if the forks you suggest were long-lived and blurred the
> Equinox work for us or observers. I suggest that as a group we decide on
a
> path and focus our efforts in that direction. Private, long-lived forks
> should be held locally.
I agree that we need a focused effort and a group decision.
However, as you said, it is good to have branches of investigation,
even if it means putting them on the back-burner for a while.
The goal here is to put the questions out so that we could get quick
feedback and move faster to a group decision.
Cheers,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
> > 1) Multi-version or not.
> Many of the people on the Eclipse team as well as users feel that the
> compelling multiple version usecases are real and must continue to be
> supported by Eclipse. To some people this as a lot of work to support a
few
> fringe things like multiple versions of Xerces.
Agreed, I wanted to hear such support for multi-libraries from others.
> Having multiple versions enables the
> integration of independent plugin wads(aka products) into the same Eclipse
> runtime.
Just a bit quick here... I agree it helps but this is only true for
libraries...
not for plugins with extensions or extension points... this indirectly
suggests that products will only share libraries, no plugins with extensions
or extension points. Do people feel confortable with just sharing
libraries between products?
Also, I would like to hear how likely those libraries are sharable at all?
This is the reverse problem. Today, Eclipse is always sharing plugins.
However, I would argue that a lot of Java library are assuming a single
application context. So how safe is it to not be able to have a private
copy of a library?
> > I personally would vote for no-multi version, at both level. I don't
like to
> > see a programming model exposing a multi-version concept for both
packages
> > and services. Note that the scope model allows to have multi-version
> > across scopes but retain a single-version API.
>
> I am not sure what you mean here. No one is proposing that a particular
> piece of code be exposed to multiple versions of the packages or services
it
> consumes. The whole point of scopes, requires/provides, whatever is to
> allow for multiple versions of packages/bundles to exist in the runtime
but
> yet have any given consumer see only the version dictated by their scope,
> requires list, ...
Agreed, and also agreed that this is what we are trying to do with the
different models we are exploring for supporting multi-version.
I will actually post the scope-based model pretty soon.
What I mean is that we need to be very carefull with our
model in order to not show multi-version programmatically---
for Java packages, services, and extension points.
> The only code that would be seeing multiple versions would be the
> management/admin code which necessarily needs the global view.
Agreed.
> > 2) Separate space for plugin names and extension point names.
> >
> I understand the merits of having a mechanism which has this sort of
> separation but suspect that services can satisfy that demand. In what way
> are services insufficient for the usecases you see?
For me, extension points and services are two different mechanisms
for inteoperability and extensibility. They do not oppose, they are
complementary.
Therefore, it seems logical that both would have the same flexibility.
I just don't see why we would impose services if someone wants
flexibility and extension points if not.
Fundamentally, if I understand you correctly, you see extension points
as a mean to extend a component, from a give provider. The independence
between API and implementation is for that provider to provide different
versions of the same component.
In my case, I see extension points as being a part of an API, like Java
packages
or services. They represent a functionality, not a component. They are
independent
of any provider and any provider can provide the functionality with any
combination
of plugins. Of course, permissions should allow an administrator to control
such
ability to replace a functionality.
>
> > 3) Virtualize install.
> >
> What scenarios or usecases are solved by this extra mechanism? It has the
> unfortunate effect of tying an otherwise independent layer above the
> framework (the registry stuff) into the layer below (bundle resolution).
>
Tying... you are making it sound like there is no tie today...and this is
a bad thing... I guess you don't like it. :-)
There is not extra tie, just a possibility if one wishes to
exploit it. The registry is tied anyway to the bundle resolution since a
plugin can only be visible in the registry if its bundle is resolved.
The question here is about the update manager. Should the update manager
have a chance of introspecting the Eclipse registry before committing
changes
to bundles or not?
Cheers,
Olivier.
|
|
|
| Re: decisions going forward [message #26777 is a reply to message #26622] |
Thu, 19 June 2003 12:56 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:bcse53$p7l$1@rogue.oti.com...
> > > 1) Multi-version or not.
> > Many of the people on the Eclipse team as well as users feel that the
> > compelling multiple version usecases are real and must continue to be
> > supported by Eclipse. To some people this as a lot of work to support a
> few
> > fringe things like multiple versions of Xerces.
>
> Agreed, I wanted to hear such support for multi-libraries from others.
>
> > Having multiple versions enables the
> > integration of independent plugin wads(aka products) into the same
Eclipse
> > runtime.
>
> Just a bit quick here... I agree it helps but this is only true for
> libraries...
> not for plugins with extensions or extension points... this indirectly
> suggests that products will only share libraries, no plugins with
extensions
> or extension points. Do people feel confortable with just sharing
> libraries between products?
>
> Also, I would like to hear how likely those libraries are sharable at all?
> This is the reverse problem. Today, Eclipse is always sharing plugins.
> However, I would argue that a lot of Java library are assuming a single
> application context. So how safe is it to not be able to have a private
> copy of a library?
Hmmm, miscommunication? I am saying that having multiple versions allows
products to have their own private copy. It means that I don't have to use
the same Xerces as you. *Non*library plugins are the things that must be
shared (since there can only be one of them, everyone must use the same
one).
A subtle implication in your statement is that a product would want to
ensure it had its own copy of Xerces (for example) even if other products in
the system could share the same version. This seems useful but feels like
a somewhat separate issue.
> > > 2) Separate space for plugin names and extension point names.
> > >
> > I understand the merits of having a mechanism which has this sort of
> > separation but suspect that services can satisfy that demand. In what
way
> > are services insufficient for the usecases you see?
>
> For me, extension points and services are two different mechanisms
> for inteoperability and extensibility. They do not oppose, they are
> complementary.
Agreed.
> Therefore, it seems logical that both would have the same flexibility.
> I just don't see why we would impose services if someone wants
> flexibility and extension points if not.
>
> Fundamentally, if I understand you correctly, you see extension points
> as a mean to extend a component, from a give provider. The independence
> between API and implementation is for that provider to provide different
> versions of the same component.
>
> In my case, I see extension points as being a part of an API, like Java
> packages
> or services. They represent a functionality, not a component. They are
> independent
> of any provider and any provider can provide the functionality with any
> combination
> of plugins. Of course, permissions should allow an administrator to
control
> such
> ability to replace a functionality.
Right. So we look at this completely differently. Extension points, as the
name implies, are a plugin's way of saying, "hey, here is a point at which
you can configure/extend me and I will use what you provide in this way...".
It is part of the API of that plugin. In some cases, the same effect can be
had programmatically.
> >
> > > 3) Virtualize install.
> > >
> > What scenarios or usecases are solved by this extra mechanism? It has
the
> > unfortunate effect of tying an otherwise independent layer above the
> > framework (the registry stuff) into the layer below (bundle resolution).
> >
>
> Tying... you are making it sound like there is no tie today...and this is
> a bad thing... I guess you don't like it. :-)
> There is not extra tie, just a possibility if one wishes to
> exploit it. The registry is tied anyway to the bundle resolution since a
> plugin can only be visible in the registry if its bundle is resolved.
>
> The question here is about the update manager. Should the update manager
> have a chance of introspecting the Eclipse registry before committing
> changes
> to bundles or not?
To me the update manager would work on bundles at the OSGi framework level.
The Eclipse extension registry is a passive participant (unknown to the
framework) in that it listens for framework resolved events and updates the
extension registry. This proposal requires the framework to consult with a
layer above (the extension registry) which it previously did not know about.
Now, if you are suggesting a general mechanism for opening up the frameworks
resolution algorithm then I am more excited. I personally would not seek to
use it to tie in extension/extension point matching however.
Jeff
|
|
|
| Re: decisions going forward [message #26816 is a reply to message #26777] |
Thu, 19 June 2003 14:26 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
> Right. So we look at this completely differently. Extension points, as
the
> name implies, are a plugin's way of saying, "hey, here is a point at which
> you can configure/extend me and I will use what you provide in this
way...".
> It is part of the API of that plugin. In some cases, the same effect can
be
> had programmatically.
That's cool. If no one sees an interest, we will just keep it as it is
in Eclipse.
>
> To me the update manager would work on bundles at the OSGi framework
level.
> The Eclipse extension registry is a passive participant (unknown to the
> framework) in that it listens for framework resolved events and updates
the
> extension registry.
Agreed.
> This proposal requires the framework to consult with a
> layer above (the extension registry) which it previously did not know
about.
>
No, this proposal does not change the frameworks. The framework decides
on its own if a bundle is resolved or not. But remember, this happens in a
two-phase approach. Hence, the update manager (not the framework)
may introspect the Plugin registry (future state) and use what it sees to
apply policies to determine if the resulting configuration is acceptable or
not.
By introspecting both the OSGi layer (service and package resolution) and
the plugin registry (extension points), the update manager has a global
understanding
of what is going on and may commit or abort the install.
> Now, if you are suggesting a general mechanism for opening up the
frameworks
> resolution algorithm then I am more excited.
No I am not, I am just saying that the OSGi framework may not be the only
container/registry to consult in order to decide if a set of
updates/installs
are acceptable or not.
Olivier.
|
|
| | | |
| Re: decisions going forward [message #27346 is a reply to message #27285] |
Wed, 02 July 2003 10:53 |
| Eclipse User |
|
|
|
I think this is an important thing.
If Eclipse is running on an OSGi framework then yes, in theory, any
OSGi-based update/install mechansim would be able to
install/update/remove bundles into the framework and thus
install/update/remove eclipse. However the OSGi framework is only going
to know about classloader/namespace dependency resolution. The
"try-before-you-buy" modeling that this layer can add can only flag
conflicts at that level. Thus installation of eclipse 'plundles' by
this mechansim means that extension/extension-point resolution would
still be a blind date experience: You install it and see what happens.
So the argument is that we need to provide a service that exposes a way
to predictively model the results of extension-point/extension
dependency resolution in parallel. This could be ignored by osgi bundle
installation mechanisms that don't really know about eclipse, but
_Eclipse-aware_ installation/update/removal mechanisms would know to
interrogate that service as well when doing predictive modeling prior to
an install/update/removal.
Another alternative is to have the framework's bundle dependency
resolution service expose a hook that would allow additional resolution
layers to be included. In other words, the framework bundle dependency
resolution service would expose a service allowing other registries to
register for callbacks before/after the bundle resolution so they can
apply their two cents before the framework bundle resolution service
returns it's results.
I like this last idea because it would not require special Eclipse
awareness on the part of osgi bundle installers. Also, it is general
enough that it supports the idea of hooks for other types of registries
sitting on top of the framework.
Thoughts?
Olivier Gruber wrote:
>>General mechanism for updating:
>>I wonder why you are against providing an general mechanism (maybe simply
>
> a
>
>>couple of API and a service)?
>
>
> I am not against at all, on the contrary.
> I am proposing to bolt down the Eclipse plugin registry with the OSGi layer.
> The registry is simply a service above OSGi. But it offers a two-phase
> admin API to itself. You are totally correct below, if you are interested
> to know the impacts of your installs on the registry, you find the registry
> service, you ask for its admin API, and you introspect.
> This is exactly what I have in mind.
>
>
>
>>In my mind, this would simply give install/update tools a unique place to
>>discover actors that need to be consulted while the install/update.
>>
>>An attempt to be more concrete:
>> - the framework declares a minimal interface that allows to get
>>information about the future state (correct/incorrect). This interface is
>>used through services.
>> - a model provider implements this interface and a service.
>>
>>Now an install/update tool can discover the different providers, and
>
> consult
>
>>them all to know if they liked the install.
>>
>>In the case where a model provider wants to create a better install/update
>>tool it can still take advantage of this API to find its service.
>>
>> PaScaL
>>
>>
>
>
>
|
|
|
| Re: decisions going forward [message #27821 is a reply to message #27346] |
Wed, 02 July 2003 17:24 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:bdurlm$lal$1@rogue.oti.com...
> I think this is an important thing.
>
> If Eclipse is running on an OSGi framework then yes, in theory, any
> OSGi-based update/install mechansim would be able to
> install/update/remove bundles into the framework and thus
> install/update/remove eclipse. However the OSGi framework is only going
> to know about classloader/namespace dependency resolution. The
> "try-before-you-buy" modeling that this layer can add can only flag
> conflicts at that level. Thus installation of eclipse 'plundles' by
> this mechansim means that extension/extension-point resolution would
> still be a blind date experience: You install it and see what happens.
>
> So the argument is that we need to provide a service that exposes a way
> to predictively model the results of extension-point/extension
> dependency resolution in parallel. This could be ignored by osgi bundle
> installation mechanisms that don't really know about eclipse, but
> _Eclipse-aware_ installation/update/removal mechanisms would know to
> interrogate that service as well when doing predictive modeling prior to
> an install/update/removal.
>
> Another alternative is to have the framework's bundle dependency
> resolution service expose a hook that would allow additional resolution
> layers to be included. In other words, the framework bundle dependency
> resolution service would expose a service allowing other registries to
> register for callbacks before/after the bundle resolution so they can
> apply their two cents before the framework bundle resolution service
> returns it's results.
>
> I like this last idea because it would not require special Eclipse
> awareness on the part of osgi bundle installers. Also, it is general
> enough that it supports the idea of hooks for other types of registries
> sitting on top of the framework.
I personally like this idea but would not particularly use it for
extension/extension point resolution (see below). It is interesting to
allow for alternative bundle resolution algorithms which have different
weightings for local vs global constraint satisfaction, least perturbation
models, ... While this pluggable resolver approach certainly could be a
part of a given implementation, it may make sense for it to be a part of
OSGi itself. Either way, an OSGi installer using the try-before-you-buy
mechanisms will be able to take advantage of this characteristic.
As for extension point resolution, I think this is an unnecessary
complication. I still feel that people are making too much of
extensions/extension points. I would like to see a relaxing of the
requirement for extension/extension point bearing plugins to be singletons
in the system but this still does not mean that a plugin should be left
unresolved if its extensions cannot be matched to an extension point.
Jeff
|
|
|
| Re: decisions going forward [message #27861 is a reply to message #27821] |
Wed, 02 July 2003 18:16 |
| Eclipse User |
|
|
|
Jeff McAffer wrote:
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:bdurlm$lal$1@rogue.oti.com...
>
>>
>>Another alternative is to have the framework's bundle dependency
>>resolution service expose a hook that would allow additional resolution
>>layers to be included. In other words, the framework bundle dependency
>>resolution service would expose a service allowing other registries to
>>register for callbacks before/after the bundle resolution so they can
>>apply their two cents before the framework bundle resolution service
>>returns it's results.
>>
>>I like this last idea because it would not require special Eclipse
>>awareness on the part of osgi bundle installers. Also, it is general
>>enough that it supports the idea of hooks for other types of registries
>>sitting on top of the framework.
>
>
> I personally like this idea but would not particularly use it for
> extension/extension point resolution (see below). It is interesting to
> allow for alternative bundle resolution algorithms which have different
> weightings for local vs global constraint satisfaction, least perturbation
> models, ... While this pluggable resolver approach certainly could be a
> part of a given implementation, it may make sense for it to be a part of
> OSGi itself. Either way, an OSGi installer using the try-before-you-buy
> mechanisms will be able to take advantage of this characteristic.
>
> As for extension point resolution, I think this is an unnecessary
> complication. I still feel that people are making too much of
> extensions/extension points. I would like to see a relaxing of the
> requirement for extension/extension point bearing plugins to be singletons
> in the system but this still does not mean that a plugin should be left
> unresolved if its extensions cannot be matched to an extension point.
>
> Jeff
>
>
After discussions on the side with Keith, I'm starting to agree that it
may be okay to leave extensions dangling (not saying I'm 100% on board
though). I still like the idea of creating a hook in the framework
resolution layer for connecting additional registries to the process.
We could then always hook the registry resolution in if we find that we
have a usecase that makes it important.
The input to the hook could simply be a list of bundles and the return
value would be a list of bundles plus status information
(resolved/unresolved/specifi problem meta info, etc.) for each. That
should be sufficiently general.
You are correct that this belongs in the OSGi framework layer.
Mel
|
|
|
Goto Forum:
Current Time: Wed May 07 14:15:53 EDT 2025
Powered by FUDForum. Page generated in 0.04410 seconds |
Home