Home » Eclipse Projects » Equinox » Independence API --- Implementation
| Independence API --- Implementation [message #26384] |
Wed, 18 June 2003 19:39  |
|
Originally posted by: ogruber.us.ibm.com
From a programming model, Eclipse promotes encapsulation
and the independence between a plugin API and its implementation.
However, from a configuration standpoint, Eclipse seems to promote
expressing pre-requisites in terms of implementations, not APIs.
This is very visible in the PluginRegistry around extensions and
extension points.
The extension points for a plugin can only be defined/provided
by that plugin. Indeed, all extension point names are created by
prefixing the local name with the plugin name. So for instance,
all extension points from the UI plugin are named as org.eclipse.ui.xyz.
I believe this approach does not allow enough flexibility and I would
like to get feedback on this issue. Let's look at examples to fuel the
discussion...
1) Limiting reorganization capabilities.
I believe this seriously limits one's ability to reorganize plugins.
Let suppose a plugin A is restructured in a plugin A1 and A2.
In fact, let suppose also that A1 and A2 could be used together
or independently. Well, this reorganisation is not possible since
it is impossible to move extension points accordingly to A1 and A2,
allowing them to be used independently.
2) Limiting flexibility in assembly.
Like with interfaces and abstract classes, there will be plugins for which
alternative implementations will be attractive while maintaining the API for
compatibility. Many examples can be thought of.
First, let's suppose that someone wants to change the UI framework.
The API is fine, but he or she wants to experiment with different metaphores
for integrating perspectives and views. This is not possible because no
other
plugin can actually provide the extension points of the org.eclipse.ui
plugin.
Second, let suppose that someone wants to improve/modify the resource
plugin. For instance, one wants the ability to integrate replicated data
sources
as shared resources for plugins. Or, someone wants to use another storage
medium than straight files, maybe a database. Again not possible, no other
provider than Eclipse can provide a plugin com.zyz.resources that would
provide the same API as org.eclipse.core.resources.
3) Third-party Dependence
Let's suppose a company XYZ depends on a third-party plugin Foo from
company PQR (com.pqr.foo). So many products from company XYZ have
pre-requisites in terms of the plugin Foo. For many reasons, the company XYZ
may want to change its supplier of the plugin Foo. It is possible but rather
complicated. It has to re-deploy all its products with the update
pre-requisite,
let's say on an internal plugin Bar (com.xyz.bar).
If the dependency would have been expressed in terms only of extension
point,
and the name space of extension points and plugins would be disjoint,
only the update of the plugin com.pqr.foo by com.xyz.bar would have been
necessary.
This gives raise to an interesting point about the update manager.
It becomes much more of an integrator than before. In our case,
the platform would have both plugins (com.pqr.foo and com.xyz.bar),
providing the same API (Java packages and extension points).
The end user would have to decide which plugin should be used.
This is too hard for most average end users, so the metadata at the
feature level could be extended with extra plugin-level requisites.
So the update would really be at the feature level, indicating that
the pre-requisite update is from com.pqr.foo to com.xyz.bar.
None of the plugin.xml have to be changed, none of the plugins
have to be redeployed.
4) Others... ?
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
|
|
|
| Re: Independence API --- Implementation [message #26492 is a reply to message #26384] |
Wed, 18 June 2003 22:42  |
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:bcqtd6$nej$1@rogue.oti.com...
> From a programming model, Eclipse promotes encapsulation
> and the independence between a plugin API and its implementation.
> However, from a configuration standpoint, Eclipse seems to promote
> expressing pre-requisites in terms of implementations, not APIs.
> This is very visible in the PluginRegistry around extensions and
> extension points.
>
> The extension points for a plugin can only be defined/provided
> by that plugin. Indeed, all extension point names are created by
> prefixing the local name with the plugin name. So for instance,
> all extension points from the UI plugin are named as org.eclipse.ui.xyz.
>
> I believe this approach does not allow enough flexibility and I would
> like to get feedback on this issue. Let's look at examples to fuel the
> discussion...
>
> 1) Limiting reorganization capabilities.
>
> I believe this seriously limits one's ability to reorganize plugins.
> Let suppose a plugin A is restructured in a plugin A1 and A2.
> In fact, let suppose also that A1 and A2 could be used together
> or independently. Well, this reorganisation is not possible since
> it is impossible to move extension points accordingly to A1 and A2,
> allowing them to be used independently.
This one is a bummer. When the Eclipse UI plugin was refactored, the
extension points were all left on the UI plugin and accessed/used from the
new "child" plugins. This is a bit distasteful in the implementation
(coming from the standard Eclipse mindset). On the other hand, it would be
reasonably easy to structure the code such that the UI plugin had API
enabling access to the configured extensions. Since the UI plugin reexports
its children, it is the one presenting the API face to the world anyway.
This enhances encapsulation in the sense that consumers need not know if the
UI is one plugin or 20.
> 2) Limiting flexibility in assembly.
> ...
> 3) Third-party Dependence
> ...
These two usecases are really arguing that a) Eclipse should not be an
integration platform and b) that services should be used more throughout
Eclipse.
In #2 you speculate that someone wants to replace the UI or resources
plugins. I can certainly see the attraction but it is a design point of
Eclipse that it is an *integration* platform. By definition that means it
provides a known base in which things come together. The UI plugin is not
supposed to pluggable.
#3 is a classic service model argument. And I agree completely! Services
are good. People should use them. Eclipse should use them more. Extension
points/extensions are not services.
> This gives raise to an interesting point about the update manager.
> It becomes much more of an integrator than before. In our case,
> the platform would have both plugins (com.pqr.foo and com.xyz.bar),
> providing the same API (Java packages and extension points).
> The end user would have to decide which plugin should be used.
>
> This is too hard for most average end users, so the metadata at the
> feature level could be extended with extra plugin-level requisites.
> So the update would really be at the feature level, indicating that
> the pre-requisite update is from com.pqr.foo to com.xyz.bar.
> None of the plugin.xml have to be changed, none of the plugins
> have to be redeployed.
Unless I misunderstand, you are highlighting that your approach makes the
system more complex to configure and describe. It brings features closer
into the runtime (i.e., adds another concept to the runtime) and increases
the constraint expressions which have to be defined/managed by someone.
Jeff
|
|
| |
| Re: Independence API --- Implementation [message #26657 is a reply to message #26492] |
Thu, 19 June 2003 09:35 |
|
Originally posted by: ogruber.us.ibm.com
> > 1) Limiting reorganization capabilities.
> >
> > I believe this seriously limits one's ability to reorganize plugins.
> > Let suppose a plugin A is restructured in a plugin A1 and A2.
> > In fact, let suppose also that A1 and A2 could be used together
> > or independently. Well, this reorganisation is not possible since
> > it is impossible to move extension points accordingly to A1 and A2,
> > allowing them to be used independently.
>
> This one is a bummer. When the Eclipse UI plugin was refactored, the
> extension points were all left on the UI plugin and accessed/used from the
> new "child" plugins. This is a bit distasteful in the implementation
> (coming from the standard Eclipse mindset). On the other hand, it would
be
> reasonably easy to structure the code such that the UI plugin had API
> enabling access to the configured extensions. Since the UI plugin
reexports
> its children, it is the one presenting the API face to the world anyway.
> This enhances encapsulation in the sense that consumers need not know if
the
> UI is one plugin or 20.
>
You lost me there... maybe there is something I don't understand.
But I thought that extension point names where prefixed automatically
by their plugin name. So I thought that is not possible to move extension
points from the UI plugin to other plugins. So my example still stands as
something not possible. Correct?
However, I agree with you that UI abstract away how many plugins it uses
internally through the re-export mechanism.
Olivier.
|
|
|
| Re: Independence API --- Implementation [message #26698 is a reply to message #26492] |
Thu, 19 June 2003 09:58 |
|
Originally posted by: ogruber.us.ibm.com
> These two usecases are really arguing that a) Eclipse should not be an
> integration platform and b) that services should be used more throughout
> Eclipse.
>
> In #2 you speculate that someone wants to replace the UI or resources
> plugins. I can certainly see the attraction but it is a design point of
> Eclipse that it is an *integration* platform. By definition that means it
> provides a known base in which things come together. The UI plugin is not
> supposed to pluggable.
Well, I can see you definition of an integration platform.
I could even agree with you about that it means it provides a known
base in which things come together... but I don't agree it implies that
it means a single versioned implementation from a single provider.
I like the fact that in UNIX I can change the windowing manager or change
the widget toolkit. I like micro-kernels where file systems implementations
could be replaced. I don't like Microsoft Windows environment where so
many things are bolt down.
I totally agree with you that the concept of profiles for integration is a
great
concept. I am just disagreeing that it should be expressed on
implementations
rather than clean APIs with repleacable implementations.
>
> #3 is a classic service model argument. And I agree completely! Services
> are good. People should use them. Eclipse should use them more.
Extension
> points/extensions are not services.
>
See my other posting... yes, extension points are not services... but no,
I don't see why they should not benefit from the same flexibility between
APIs and implementations.
> > This gives raise to an interesting point about the update manager.
> > It becomes much more of an integrator than before. In our case,
> > the platform would have both plugins (com.pqr.foo and com.xyz.bar),
> > providing the same API (Java packages and extension points).
> > The end user would have to decide which plugin should be used.
> >
> > This is too hard for most average end users, so the metadata at the
> > feature level could be extended with extra plugin-level requisites.
> > So the update would really be at the feature level, indicating that
> > the pre-requisite update is from com.pqr.foo to com.xyz.bar.
> > None of the plugin.xml have to be changed, none of the plugins
> > have to be redeployed.
>
> Unless I misunderstand, you are highlighting that your approach makes the
> system more complex to configure and describe. It brings features closer
> into the runtime (i.e., adds another concept to the runtime) and increases
> the constraint expressions which have to be defined/managed by someone.
>
More complex or more flexible and powerful. I guess it depends on your
point of view. Yes, you are correct that it brings a notion of assembly of
plugins closer to the runtime. Does it make the system more complex to
configure and describe. No, not at all, actually quite the contrary.
I don't believe in the current Eclipse approach where the runtime
unilaterally decides what is the configuration, that is, decide which
plugins to keep and which plugins to toss---at startup time.
I believe that it should be an install-time decision. When a new product
is installed, the conflicts and sharing issues should be resolved then,
by whoever is in charge of the platform. Those decisions should be
changeable later on, while the system is running. In other words,
a product would express a configuration that it tested and can vouch
for. However, someone integrating different products, or simply the
administrator of a machine, should be allowed to overrule that
configuration. This requires to distinguish between pre-requisites
in terms of API from configuration hints in terms of implementations.
Cheers,
Olivier.
|
|
|
| Re: Independence API --- Implementation [message #26855 is a reply to message #26698] |
Thu, 19 June 2003 16:13 |
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:bcsfnk$qsf$1@rogue.oti.com...
>
> > These two usecases are really arguing that a) Eclipse should not be an
> > integration platform and b) that services should be used more throughout
> > Eclipse.
> >
> > In #2 you speculate that someone wants to replace the UI or resources
> > plugins. I can certainly see the attraction but it is a design point of
> > Eclipse that it is an *integration* platform. By definition that means
it
> > provides a known base in which things come together. The UI plugin is
not
> > supposed to pluggable.
>
> Well, I can see you definition of an integration platform.
> I could even agree with you about that it means it provides a known
> base in which things come together... but I don't agree it implies that
> it means a single versioned implementation from a single provider.
>
> I like the fact that in UNIX I can change the windowing manager or change
> the widget toolkit. I like micro-kernels where file systems
implementations
> could be replaced. I don't like Microsoft Windows environment where so
> many things are bolt down.
Hmmm, using different window managers seems more like skinning. It is
relativley superficial. Changing widget toolkits is in fact cool. However,
its not like you can take app A and decide to run it on Motif then change
and run it on GTK. The app has to be written to use the particular libs.
As a result, Motif and GTK apps are not integrated in any deep/useful way.
The analog in Eclipse is that you can come along and provide a completely
different UI (say com.cool.ui) and people can buy into that UI
model/presentation/... and write their plugins against that API (including
extension points). The result would be two different UI systems running in
the same VM on the same Eclipse runtime but with little UI integration. We
are not going out of our way to support this because we want Eclipse to be
the point of integration for the runtime and UI.
> > > This gives raise to an interesting point about the update manager.
> > > It becomes much more of an integrator than before. In our case,
> > > the platform would have both plugins (com.pqr.foo and com.xyz.bar),
> > > providing the same API (Java packages and extension points).
> > > The end user would have to decide which plugin should be used.
> > >
> > > This is too hard for most average end users, so the metadata at the
> > > feature level could be extended with extra plugin-level requisites.
> > > So the update would really be at the feature level, indicating that
> > > the pre-requisite update is from com.pqr.foo to com.xyz.bar.
> > > None of the plugin.xml have to be changed, none of the plugins
> > > have to be redeployed.
> >
> > Unless I misunderstand, you are highlighting that your approach makes
the
> > system more complex to configure and describe. It brings features
closer
> > into the runtime (i.e., adds another concept to the runtime) and
increases
> > the constraint expressions which have to be defined/managed by someone.
>
> More complex or more flexible and powerful. I guess it depends on your
> point of view. Yes, you are correct that it brings a notion of assembly of
> plugins closer to the runtime. Does it make the system more complex to
> configure and describe. No, not at all, actually quite the contrary.
> I don't believe in the current Eclipse approach where the runtime
> unilaterally decides what is the configuration, that is, decide which
> plugins to keep and which plugins to toss---at startup time.
>
> I believe that it should be an install-time decision. When a new product
> is installed, the conflicts and sharing issues should be resolved then,
> by whoever is in charge of the platform. Those decisions should be
> changeable later on, while the system is running. In other words,
> a product would express a configuration that it tested and can vouch
> for. However, someone integrating different products, or simply the
> administrator of a machine, should be allowed to overrule that
> configuration. This requires to distinguish between pre-requisites
> in terms of API from configuration hints in terms of implementations.
I think we are actually agreeing here more than it seems. I fully support
the role of "systems integrator" and their need to take a bigger picture
view of the world. This is goodness regardless of the nature of extension
points etc. We can fork a new discussion thread for that if you like.
Jeff
|
|
|
| Re: Independence API --- Implementation [message #26895 is a reply to message #26657] |
Thu, 19 June 2003 16:15 |
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:bcsecp$pf8$1@rogue.oti.com...
> > This one is a bummer. When the Eclipse UI plugin was refactored, the
> > extension points were all left on the UI plugin and accessed/used from
the
> > new "child" plugins. This is a bit distasteful in the implementation
> > (coming from the standard Eclipse mindset). On the other hand, it would
> be
> > reasonably easy to structure the code such that the UI plugin had API
> > enabling access to the configured extensions. Since the UI plugin
> reexports
> > its children, it is the one presenting the API face to the world anyway.
> > This enhances encapsulation in the sense that consumers need not know if
> the
> > UI is one plugin or 20.
> >
>
> You lost me there... maybe there is something I don't understand.
> But I thought that extension point names where prefixed automatically
> by their plugin name. So I thought that is not possible to move extension
> points from the UI plugin to other plugins. So my example still stands as
> something not possible. Correct?
Correct. The extension points are not moved, they are just accessed from
other plugins.
> However, I agree with you that UI abstract away how many plugins it uses
> internally through the re-export mechanism.
>
> Olivier.
>
>
|
|
|
| Re: Independence API --- Implementation [message #26933 is a reply to message #26549] |
Thu, 19 June 2003 16:29 |
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:bcrm2q$562$1@rogue.oti.com...
> Jeff McAffer wrote:
> > "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> > news:bcqtd6$nej$1@rogue.oti.com...
> So you are saying that being an "integration platform" is incompatible
> with a pluggable UI? I don't think I believe that is an unchallengable
> truth. It may be an aspect of the Eclipse design, but I don't think
> that that is necessarily true or desirable in general.
I overstated my point. Just decoupling the extension points is not enough
to do what you are after. The UI plugin is not service oriented. So UI
"clients" prereq the org.eclipse.ui plugin, use classes which are
org.eclipse.ui.*, extend org.eclipse.ui.* extension points... The issues
raised by these characteristics seem worse/harder than the extension point
coupling issue. How does someone wanting to replace the UI plugin address
the fact, for example, that everyone "requires" it (and thus gets their
classes from it)?
> In order to integrate UI extensions it seems reasonable to require _a_
> UI-providing extension-point, but I don't see why it necessarily follows
> that it must be ONE particular UI-providing extension-point.
>
> > #3 is a classic service model argument. And I agree completely!
Services
> > are good. People should use them. Eclipse should use them more.
Extension
> > points/extensions are not services.
> >
>
> I'm not sure what your point here is. The fact is that if a services
> model required that the client request a service by requiring a
> particular implementation of a service, then it would result in the same
> problem.
>
> The extension point/extension model is designed so that the extension
> implementer must state who is going to use the extension. That is like
> a service stating who it's client will be when it registers the service.
> (Hmm... why extensions ARE services - and extension-points ARE
> clients! :-)
You can map extension points/extensions onto services but again, that is not
what extension points are designed to be. They are points at which the
defining plugin can be extended or configured. Inherent in that is the
notion that there is one "client". Again, I like services and think they
are very useful and should be used more. It is also possible that many of
the things which are currently expressed as extension points would be better
as services. Either way, they are different but complementary mechanisms.
Jeff
|
|
|
| Re: Independence API --- Implementation [message #27093 is a reply to message #26933] |
Sun, 22 June 2003 00:11 |
 Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Jeff McAffer wrote:
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:bcrm2q$562$1@rogue.oti.com...
>
>>Jeff McAffer wrote:
>>
>>>"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
>>>news:bcqtd6$nej$1@rogue.oti.com...
>>
>>So you are saying that being an "integration platform" is incompatible
>>with a pluggable UI? I don't think I believe that is an unchallengable
>>truth. It may be an aspect of the Eclipse design, but I don't think
>>that that is necessarily true or desirable in general.
>
>
> I overstated my point. Just decoupling the extension points is not enough
> to do what you are after. The UI plugin is not service oriented. So UI
> "clients" prereq the org.eclipse.ui plugin, use classes which are
> org.eclipse.ui.*, extend org.eclipse.ui.* extension points... The issues
> raised by these characteristics seem worse/harder than the extension point
> coupling issue. How does someone wanting to replace the UI plugin address
> the fact, for example, that everyone "requires" it (and thus gets their
> classes from it)?
>
I am aware of this 'additional problem', but that is a problem of code
organization and the way classpath dependencies are currently expressed
(something I thought we were going to try to address). This and the
main problem we are discussing (extension points being tied to a
particular plugin) could both be solved by modifying the current
declarative registration mechanism.
The real problem is not a programmatic one or an issue of runtime
functionality. There is nothing in theory stoping me from supplying my
own UI plugin that interrogates the registry to find and use extensions
meant for the workbench. The 'requires' aspect of the problem is that
the current packaging of classes forces me to still supply all of the
current extension-point provider plugin, in order to satisfy the
requires of the extension providers. This in itself is not the worst of
things, but it would be nice to avoid.
Other folks may have better ideas, but it seems to me that simply adding
some sort of alias mechanism to the mix would resolve this. It would
allow one to say in the plugin.xml that "I would like to recieve
extensions for plugin A's extension-point" and "I can satisfy
requirements for plugin A". And the latter would be solved if class
dependencies were specified based on specification rather than
implementation.
>
> You can map extension points/extensions onto services but again, that is not
> what extension points are designed to be. They are points at which the
> defining plugin can be extended or configured. Inherent in that is the
> notion that there is one "client". Again, I like services and think they
> are very useful and should be used more. It is also possible that many of
> the things which are currently expressed as extension points would be better
> as services. Either way, they are different but complementary mechanisms.
>
I don't really want to get too far into a debate about design philosophy
or what the intentions of the current design are/are not. Suffice to
say that I think that you are making an unnecessary distinction. All
code is client-server. Extension-providers make use of extensions
through a functional interface. The only real question is how clients
discover services. It is the nature of the eclipse
extension-point/extension registry mechanism to favor a
1-client-to-many-services relationship by way of a discovery protocol
that keys off a name associated with a particular client.
It seems a logical next step to decouple the key from a particular
client. That is the only real difference between the current eclipse
mechanism and a 'traditional' service mechanism.
Mel
|
|
|
| Re: Independence API --- Implementation [message #27249 is a reply to message #27093] |
Mon, 23 June 2003 22:07 |
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:bd3aqc$27e$1@rogue.oti.com...
> Jeff McAffer wrote:
> > "Mel Martinez" <melm@us.ibm.com> wrote in message
> > news:bcrm2q$562$1@rogue.oti.com...
> >
> The real problem is not a programmatic one or an issue of runtime
> functionality. There is nothing in theory stoping me from supplying my
> own UI plugin that interrogates the registry to find and use extensions
> meant for the workbench. The 'requires' aspect of the problem is that
> the current packaging of classes forces me to still supply all of the
> current extension-point provider plugin, in order to satisfy the
> requires of the extension providers. This in itself is not the worst of
> things, but it would be nice to avoid.
My point here is that if the UI plugin writers wanted to, they could have
made all of their function availalbe through regular service mechanisms
(assuming that Eclipse had such a thing). Then you would be able to get the
code flexibility you are looking for. The "requires" mechanism is really
about specifying implementation needs not functional needs. something like
the OSGi package import/export is something that addresses your concerns.
And you are right, we should/are considering this for Equinox.
> > You can map extension points/extensions onto services but again, that is
not
> > what extension points are designed to be. They are points at which the
> > defining plugin can be extended or configured. Inherent in that is the
> > notion that there is one "client". Again, I like services and think
they
> > are very useful and should be used more. It is also possible that many
of
> > the things which are currently expressed as extension points would be
better
> > as services. Either way, they are different but complementary
mechanisms.
> >
>
> I don't really want to get too far into a debate about design philosophy
> or what the intentions of the current design are/are not. Suffice to
> say that I think that you are making an unnecessary distinction. All
> code is client-server. Extension-providers make use of extensions
> through a functional interface. The only real question is how clients
> discover services. It is the nature of the eclipse
> extension-point/extension registry mechanism to favor a
> 1-client-to-many-services relationship by way of a discovery protocol
> that keys off a name associated with a particular client.
>
> It seems a logical next step to decouple the key from a particular
> client. That is the only real difference between the current eclipse
> mechanism and a 'traditional' service mechanism.
The fundamental difference is that extension points are a way of
declaratively exposing part of a plugin for extension. This may or may not
involve any code (e.g., doc extensions supply html not Java classes). I
agree that you could get close trying to map onto services but my basic
point is "why bother?". Services are there. If you want to have these
characteristics, use services in the way that you describe. Extension
points/extensions provide similar but distinctly different characteristics.
Jeff
|
|
|
Goto Forum:
Current Time: Sun May 19 03:35:41 EDT 2013
Powered by FUDForum. Page generated in 0.02141 seconds
|
] 
Search
Help
Register
Login
Home
