Home » Eclipse Projects » Equinox » Package sharing: efficiency and necessity
| Package sharing: efficiency and necessity [message #12979] |
Thu, 13 March 2003 03:37  |
Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I'd like to dig a bit deeper in the sharing of packages. I think there
are two very different reason to share a package.
1 Saving time and spacing by reuse, aka utility libs
2 Communication, aka interface libs
In a way, if you use some kind of parser library, as a user, you could
not care less if you share it or not. Only when the objects are
communicated to other plugins (assuming the environment is also treated
as a plugin) does it become -necessary- that the same classloader is
used, otherwise ClassCastExceptions will happen
A pattern I see in the market is that many applications include a lib
directory containing ALL the libs (jars) they depend on, instead of
telling the user where to find xyz.jar, version 1.0.2-beta3-build23 and
end up in "DLL hell". Obviously, we do not want to end up with 5000
plugins which each carry their private copy of Xerces. However, it seems
very attractive to have a model where each plugin could contain (or
maybe refer by location) to a set of JAR files that were used during
development instead of trying to identify those copies with a
name/version (which is VERY error prone as we all know, most DLL
problems are (were?) caused by wrong version numbers.
The classloader framework would then have to sort out the differences
and equalities. It could probably significantly optimize: persistent
storage, internal memoery and classloading time. (It could use hashing,
not version numbers/name to establish identity and then reuse).
So we could trade of space (at least in the delivery of the plugin which
may increase the communication cost, but hey, who cares nowadays?) for
significantly simplifying the versioning model.
Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
the plugin with all my linked jars and know that the environment will
take care, instead of hoping that the frigging programmer of the other
plugin has bumped the version correctly? :-) Note that most JARs I see
on the net do not have any package versions nor JAR versions today, and
I see a lot of them. (there are licensing issues, but maybe Eclipse,
among others, can be used as a repository for jars so you can have a URL
point to the right lib, we might even support such a global JAR
repository from inside Eclipse, but that is another story).
This would obviously only work for libraries that are not used for
communication. These libraries require a versioning model with backward
compatibility so that older and newer versions can keep communicating. I
am fairly convinced that a global namespace is necessary for these
"interface" libraries. It seems that a service registry for this purpose
has many qualities by encapsulating versioning problems.
This probably needs some thinking/experience because I have not tried
this out, but it has been in my mind for some time. I foresee some
issues with (the evil) static methods but that can be worked out I
think. What do you think?
Kind regards,
Peter Kriens
|
|
|
| Re: Package sharing: efficiency and necessity [message #13095 is a reply to message #12979] |
Thu, 13 March 2003 08:11  |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
pkriens wrote:
> Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
> the plugin with all my linked jars and know that the environment will
> take care, instead of hoping that the frigging programmer of the other
> plugin has bumped the version correctly? :-) Note that most JARs I see
> on the net do not have any package versions nor JAR versions today, and
> I see a lot of them. (there are licensing issues, but maybe Eclipse,
> among others, can be used as a repository for jars so you can have a URL
> point to the right lib, we might even support such a global JAR
> repository from inside Eclipse, but that is another story).
Funny you should mention it, because I have been thinking about doing
something very similar. I want to create a mechanism to handle this type
of "deployment" that specifically addresses sharing of packages for
class loading support in component-oriented frameworks, like OSGi,
Eclipse, etc. My goal is to try to deal with versioning in a better way,
like .NET, and to also support dynamics, like OSGi...I am trying to make
the mechanism neutral to any specific component model. If I can get this
off the ground, I will re-implement Oscar as an OSGi wrapper around this
mechanism...as well as create a "native" wrapper that exposes its more
advanced features.
-> richard
|
|
|
| Re: Package sharing: efficiency and necessity [message #13124 is a reply to message #13095] |
Thu, 13 March 2003 09:34 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Richard S. Hall wrote
> Funny you should mention it, because I have been thinking about doing
> something very similar. I want to create a mechanism to handle this type
> of "deployment" that specifically addresses sharing of packages for
> class loading support in component-oriented frameworks, like OSGi,
> Eclipse, etc. My goal is to try to deal with versioning in a better way,
> like .NET, and to also support dynamics, like OSGi...I am trying to make
> the mechanism neutral to any specific component model. If I can get this
> off the ground, I will re-implement Oscar as an OSGi wrapper around this
> mechanism...as well as create a "native" wrapper that exposes its more
> advanced features.
Or we try to get it standardize through the OSGi. If the model to use
the library content as its identity works, the OSGi will very likely be
interested to have a standdardized management interface.
Kind regards,
Peter Kriens
>
> -> richard
>
|
|
|
| Re: Package sharing: efficiency and necessity [message #13182 is a reply to message #13095] |
Thu, 13 March 2003 12:50 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
It seems that we are all on the same page... :-)
Peter had a very good point in another posting... side effects...
When combining potentially non-binary equivalent versions
(like in Eclipse as opposed to OSGi) with potential side
effects, a solution becomes quite delicate... :-)
Let's take the Eclipse case.
Plugins with extensions and extension points...
Plugins are versioned... major versions are incompatible,
minor-service versions are compatible...
So, the platform could correctly assume from versions,
that it is ok to load the most recent minor-service version
within each available major version. So if a plugin P is
available in P1.1, P1.2, P2.3, and P2.5.1, the platform
could both load P1.2 and P2.5.1.
However, this is not correct because of side effects...
more precisely, loaded plugins would have side effects
within the workbench and workspace... through their
extensions. The point is that versioning is not enough...
through side effects, versioning conflicts with integration.
So for instance, two views from two major versions
of the same plugins are likely to contribute the same
menus, menu items, and toolbar items... would be quite
confusing for the end user. So Eclipse forbids it...
So we are reducing multiple loading to just libraries...
meaning no extensions or extension points... but those
libraries can still have side effects...
So, should we introduce flagging plugins with side
effects or not? Should we introduce this? This seems
simple enough...
But this is not enough... we still have the problem
of the current Eclipse class loading leading to class
cast exceptions... because we load multiple versions
of compatible versions of the same plugin, driven
by strict dependencies.
Should we keep strict dependencies on binary
equivalent versions? This seems to not only introduce
non-deterministic behavior in the class loading, but it
also raise updatability issues... the more stricter the
dependencies, the harder it is to update features
without provoking multiple loading, therefore bloating the
footprint and augmenting the risk of class cast
exceptions.... and the corresponding failing extensions...
I am wondering how Microsoft.Net manages this?
Do they have compatible and incompatible versions?
Do they have a single name space for exports/imports?
How are they handling side effects ?
That is, if they really load multiple versions of libraries,
and therefore applications (since most applications are just
COM DLLs)... how do they manage all the integration
conflicts in the registry, in the startup menu, taskbar....
in all the integration points where different versions of an
application are likely to have user-visible conflicts
such as name conflicts in menus or icon conflicts in toolbars.
Anyone knows?
Any pointers ?
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
news:b4q05k$hac$1@rogue.oti.com...
> pkriens wrote:
> > Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
> > the plugin with all my linked jars and know that the environment will
> > take care, instead of hoping that the frigging programmer of the other
> > plugin has bumped the version correctly? :-) Note that most JARs I see
> > on the net do not have any package versions nor JAR versions today, and
> > I see a lot of them. (there are licensing issues, but maybe Eclipse,
> > among others, can be used as a repository for jars so you can have a URL
> > point to the right lib, we might even support such a global JAR
> > repository from inside Eclipse, but that is another story).
>
> Funny you should mention it, because I have been thinking about doing
> something very similar. I want to create a mechanism to handle this type
> of "deployment" that specifically addresses sharing of packages for
> class loading support in component-oriented frameworks, like OSGi,
> Eclipse, etc. My goal is to try to deal with versioning in a better way,
> like .NET, and to also support dynamics, like OSGi...I am trying to make
> the mechanism neutral to any specific component model. If I can get this
> off the ground, I will re-implement Oscar as an OSGi wrapper around this
> mechanism...as well as create a "native" wrapper that exposes its more
> advanced features.
>
> -> richard
>
|
|
|
| Re: Package sharing: efficiency and necessity [message #13210 is a reply to message #13182] |
Thu, 13 March 2003 14:28 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
> I am wondering how Microsoft.Net manages this?
I understand that .NET shifts the burden to the administrator. There are
XML files that explain to the environment what is compatible with what.
IMHO, this doesnt look much like a solution ... It is shifting the
burden to a person that is not well suited to handle the problem.
Kind regards,
Peter Kriens
Olivier Gruber wrote:
> It seems that we are all on the same page... :-)
> Peter had a very good point in another posting... side effects...
> When combining potentially non-binary equivalent versions
> (like in Eclipse as opposed to OSGi) with potential side
> effects, a solution becomes quite delicate... :-)
>
> Let's take the Eclipse case.
> Plugins with extensions and extension points...
> Plugins are versioned... major versions are incompatible,
> minor-service versions are compatible...
>
> So, the platform could correctly assume from versions,
> that it is ok to load the most recent minor-service version
> within each available major version. So if a plugin P is
> available in P1.1, P1.2, P2.3, and P2.5.1, the platform
> could both load P1.2 and P2.5.1.
>
> However, this is not correct because of side effects...
> more precisely, loaded plugins would have side effects
> within the workbench and workspace... through their
> extensions. The point is that versioning is not enough...
> through side effects, versioning conflicts with integration.
>
> So for instance, two views from two major versions
> of the same plugins are likely to contribute the same
> menus, menu items, and toolbar items... would be quite
> confusing for the end user. So Eclipse forbids it...
>
> So we are reducing multiple loading to just libraries...
> meaning no extensions or extension points... but those
> libraries can still have side effects...
>
> So, should we introduce flagging plugins with side
> effects or not? Should we introduce this? This seems
> simple enough...
>
> But this is not enough... we still have the problem
> of the current Eclipse class loading leading to class
> cast exceptions... because we load multiple versions
> of compatible versions of the same plugin, driven
> by strict dependencies.
>
> Should we keep strict dependencies on binary
> equivalent versions? This seems to not only introduce
> non-deterministic behavior in the class loading, but it
> also raise updatability issues... the more stricter the
> dependencies, the harder it is to update features
> without provoking multiple loading, therefore bloating the
> footprint and augmenting the risk of class cast
> exceptions.... and the corresponding failing extensions...
>
> I am wondering how Microsoft.Net manages this?
>
> Do they have compatible and incompatible versions?
> Do they have a single name space for exports/imports?
> How are they handling side effects ?
> That is, if they really load multiple versions of libraries,
> and therefore applications (since most applications are just
> COM DLLs)... how do they manage all the integration
> conflicts in the registry, in the startup menu, taskbar....
> in all the integration points where different versions of an
> application are likely to have user-visible conflicts
> such as name conflicts in menus or icon conflicts in toolbars.
>
> Anyone knows?
> Any pointers ?
>
> Best regards,
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
> news:b4q05k$hac$1@rogue.oti.com...
>
>>pkriens wrote:
>>
>>>Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
>>>the plugin with all my linked jars and know that the environment will
>>>take care, instead of hoping that the frigging programmer of the other
>>>plugin has bumped the version correctly? :-) Note that most JARs I see
>>>on the net do not have any package versions nor JAR versions today, and
>>>I see a lot of them. (there are licensing issues, but maybe Eclipse,
>>>among others, can be used as a repository for jars so you can have a URL
>>>point to the right lib, we might even support such a global JAR
>>>repository from inside Eclipse, but that is another story).
>>>
>>Funny you should mention it, because I have been thinking about doing
>>something very similar. I want to create a mechanism to handle this type
>>of "deployment" that specifically addresses sharing of packages for
>>class loading support in component-oriented frameworks, like OSGi,
>>Eclipse, etc. My goal is to try to deal with versioning in a better way,
>>like .NET, and to also support dynamics, like OSGi...I am trying to make
>>the mechanism neutral to any specific component model. If I can get this
>>off the ground, I will re-implement Oscar as an OSGi wrapper around this
>>mechanism...as well as create a "native" wrapper that exposes its more
>>advanced features.
>>
>>-> richard
>>
>>
>
>
|
|
| |
| Re: Package sharing: efficiency and necessity [message #14020 is a reply to message #13182] |
Sun, 16 March 2003 08:43 |
| Eclipse User |
|
|
|
Originally posted by: d3l3t3-heavy-n0spam.ungoverned.org
Comments below...
Olivier Gruber wrote:
> I am wondering how Microsoft.Net manages this?
>
> Do they have compatible and incompatible versions?
> Do they have a single name space for exports/imports?
> How are they handling side effects ?
> That is, if they really load multiple versions of libraries,
> and therefore applications (since most applications are just
> COM DLLs)... how do they manage all the integration
> conflicts in the registry, in the startup menu, taskbar....
> in all the integration points where different versions of an
> application are likely to have user-visible conflicts
> such as name conflicts in menus or icon conflicts in toolbars.
I think you are giving too much credit to .NET. :^)
I won't claim to know 100% what .NET is doing, but from what I
understand, it does not solve these problems.
It is my understanding that .NET is trying to solve application
isolation problems. The point is to ensure that one application will not
become unstable when another application gets installed (or removed). To
achieve this, .NET ensures that each application will get the exact
versions of libraries that it was built against. (And this is a good thing.)
This is a very important distinction. .NET deals on a per-application
basis. What we are talking about is a dynamically changing application
that has new components and thus new library requirements added to it
(and removed from it) at run time. I have not read about anything in
..NET that targets this issue.
..NET does provide "policy" files that can be specified for the
application, the library publisher, and/or for the machine that allow
you to essentially redirect the default library version bindings to
different library versions. But this is largely a manual, coarse grain
process.
Unless the .NET book that I am reading totally leaves out more
sophisticated .NET assembly issues, that's all that I understand.
We are targetting a different goal or perhaps a more expanded one...we
want not only application isolation (which we can already do with OSGi
and probably the Eclipse framework), but we want an application that can
evolve dynamically with respect to its [set of] components and their
versions.
This is more complex.
-> richard
|
|
|
| Re: Package sharing: efficiency and necessity [message #14121 is a reply to message #12979] |
Tue, 18 March 2003 14:59 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Ok, so I have tried to respond to this message three times now over the past
few days and every time Outlook crashes before I can finish. Here it goes
again... (ok, so now it is four times...)
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E704339.5040901@aQute.se...
> I'd like to dig a bit deeper in the sharing of packages. I think there
> are two very different reason to share a package.
>
> 1 Saving time and spacing by reuse, aka utility libs
> 2 Communication, aka interface libs
>
> In a way, if you use some kind of parser library, as a user, you could
> not care less if you share it or not. Only when the objects are
> communicated to other plugins (assuming the environment is also treated
> as a plugin) does it become -necessary- that the same classloader is
> used, otherwise ClassCastExceptions will happen
As you note in #1, space issues come into play with multiple copies of the
same thing loaded.
> A pattern I see in the market is that many applications include a lib
> directory containing ALL the libs (jars) they depend on, instead of
> telling the user where to find xyz.jar, version 1.0.2-beta3-build23 and
> end up in "DLL hell". Obviously, we do not want to end up with 5000
> plugins which each carry their private copy of Xerces. However, it seems
> very attractive to have a model where each plugin could contain (or
> maybe refer by location) to a set of JAR files that were used during
> development instead of trying to identify those copies with a
> name/version (which is VERY error prone as we all know, most DLL
> problems are (were?) caused by wrong version numbers.
>
> The classloader framework would then have to sort out the differences
> and equalities. It could probably significantly optimize: persistent
> storage, internal memoery and classloading time. (It could use hashing,
> not version numbers/name to establish identity and then reuse).
This is ok if you don't mind the space requirements. In general however, I
suspect people will not be happy if the *have* to ship all their
prerequisites or (on the user side) if they have to have many copies of the
prereqs installed. Just to emphasize the space issue, in some reasonable
scenarios I have run we end up with 60MB of *code* loaded. That is
bytecodes, constant pools, etc. That does NOT count object heap. Code bulk
is one of the biggest space challenges facing Eclipse and Java in general.
So, hashing et al cannot be used as it does not work for version
consolidation case. By way of background, Eclipse has a pretty
simple/powerful versioning scheme. Basically just major.minor.service.
Dependents get to spec the tightness of the constraint as exact, equivalent,
compatible or greater (in increasing looseness). Plugin providers make API
commitments along the lines of
- service = bug fixes, fully backward compatible,
- minor = bug fixes, new API/function, fully backward compatible
- major = bug fixes, new API/function, backward compatibility not required
but desirable.
see http://www.eclipse.org/eclipse/development/java-api-evolutio n.html for
more details.
> So we could trade of space (at least in the delivery of the plugin which
> may increase the communication cost, but hey, who cares nowadays?) for
> significantly simplifying the versioning model.
>
> Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
> the plugin with all my linked jars and know that the environment will
> take care, instead of hoping that the frigging programmer of the other
> plugin has bumped the version correctly? :-) Note that most JARs I see
> on the net do not have any package versions nor JAR versions today, and
> I see a lot of them. (there are licensing issues, but maybe Eclipse,
> among others, can be used as a repository for jars so you can have a URL
> point to the right lib, we might even support such a global JAR
> repository from inside Eclipse, but that is another story).
>
> This would obviously only work for libraries that are not used for
> communication. These libraries require a versioning model with backward
> compatibility so that older and newer versions can keep communicating. I
> am fairly convinced that a global namespace is necessary for these
> "interface" libraries. It seems that a service registry for this purpose
> has many qualities by encapsulating versioning problems.
>
> This probably needs some thinking/experience because I have not tried
> this out, but it has been in my mind for some time. I foresee some
> issues with (the evil) static methods but that can be worked out I
> think. What do you think?
I agree that this is an interesting direction to push. I'd like to see more
discussion of service models and how they could/should be intergrated into
Eclipse.
Jeff
Side note: I suspect alot of the challenges we will face in Equinox will be
more related to understanding how (not) to program in a dynamic environment.
|
|
|
| Re: Package sharing: efficiency and necessity [message #14189 is a reply to message #14121] |
Tue, 18 March 2003 19:23 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I think part of the problem is the different versions possible! Especially
noticeable in open source and free software, it is hard to control what
version your code depends on. If more software would have a solid design
from the get go and stick with it, only adding on to it, then we would
probably be able to put a lot more mult-used classes in a more common
location for multiple plugins to use.
On a side note, I have built my own plugin engine that will soon handle this
issue when possible. That is, my engine will allow a "parent" loader to all
plugin loaders at different levels if need be (grouping plugins with a
parent loader) that can share a common library. How I plan to work this is
not exactly "speedy" at startup. Ideally each plugin provides its own
library and the engine as it creates plugin classloaders and sets up
dependency resolution and classpaths, would examine the "same" libraries for
versions. Basically, a "crude" way to do this is check file size and
time/date stamp on the file to see if they match. If so, set that .jar
library (or .zip or .class(es)) at a "higher" classloader that the two (or
more) plugins sharing it now have their parent point to this loader, instead
of the application loader. This loader then points to the application
loader. When the JVM asks to find the class, it wont be found in each
plugin's classloader, but it will be found in their immediate parent
loader's URL classpath. The downside is figuring all this out at application
start time, so in my engine it will definitely be an optional capability.
Because the URL classpaths of each loader doesn't necessarily care about
physical location of the library, the library doesn't have to be stored in
some specific location on the disk, it can be and will be part of a plugin.
The hard part then, becomes making sure it is available so that each plugin
using it doesn't have to ship with it. I don't know how you overcome that
other than when plugins depend on a pre installed set of plugins for a given
application. I suppose the engine could "delete" a plugins libraries it
depends on if a "common" set is found, and make sure it copies at least one
of the "common" set to a given location, but that would not be good.
Basically it would only serve to make sure one version existed on the drive.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b57tqi$9ag$1@rogue.oti.com...
> Ok, so I have tried to respond to this message three times now over the
past
> few days and every time Outlook crashes before I can finish. Here it goes
> again... (ok, so now it is four times...)
>
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E704339.5040901@aQute.se...
> > I'd like to dig a bit deeper in the sharing of packages. I think there
> > are two very different reason to share a package.
> >
> > 1 Saving time and spacing by reuse, aka utility libs
> > 2 Communication, aka interface libs
> >
> > In a way, if you use some kind of parser library, as a user, you could
> > not care less if you share it or not. Only when the objects are
> > communicated to other plugins (assuming the environment is also treated
> > as a plugin) does it become -necessary- that the same classloader is
> > used, otherwise ClassCastExceptions will happen
>
> As you note in #1, space issues come into play with multiple copies of the
> same thing loaded.
>
> > A pattern I see in the market is that many applications include a lib
> > directory containing ALL the libs (jars) they depend on, instead of
> > telling the user where to find xyz.jar, version 1.0.2-beta3-build23 and
> > end up in "DLL hell". Obviously, we do not want to end up with 5000
> > plugins which each carry their private copy of Xerces. However, it seems
> > very attractive to have a model where each plugin could contain (or
> > maybe refer by location) to a set of JAR files that were used during
> > development instead of trying to identify those copies with a
> > name/version (which is VERY error prone as we all know, most DLL
> > problems are (were?) caused by wrong version numbers.
> >
> > The classloader framework would then have to sort out the differences
> > and equalities. It could probably significantly optimize: persistent
> > storage, internal memoery and classloading time. (It could use hashing,
> > not version numbers/name to establish identity and then reuse).
>
> This is ok if you don't mind the space requirements. In general however,
I
> suspect people will not be happy if the *have* to ship all their
> prerequisites or (on the user side) if they have to have many copies of
the
> prereqs installed. Just to emphasize the space issue, in some reasonable
> scenarios I have run we end up with 60MB of *code* loaded. That is
> bytecodes, constant pools, etc. That does NOT count object heap. Code
bulk
> is one of the biggest space challenges facing Eclipse and Java in general.
>
> So, hashing et al cannot be used as it does not work for version
> consolidation case. By way of background, Eclipse has a pretty
> simple/powerful versioning scheme. Basically just major.minor.service.
> Dependents get to spec the tightness of the constraint as exact,
equivalent,
> compatible or greater (in increasing looseness). Plugin providers make
API
> commitments along the lines of
> - service = bug fixes, fully backward compatible,
> - minor = bug fixes, new API/function, fully backward compatible
> - major = bug fixes, new API/function, backward compatibility not required
> but desirable.
>
> see http://www.eclipse.org/eclipse/development/java-api-evolutio n.html for
> more details.
>
> > So we could trade of space (at least in the delivery of the plugin which
> > may increase the communication cost, but hey, who cares nowadays?) for
> > significantly simplifying the versioning model.
> >
> > Wouldnt it be nice if me, as a dynamic plugin writer, could just deliver
> > the plugin with all my linked jars and know that the environment will
> > take care, instead of hoping that the frigging programmer of the other
> > plugin has bumped the version correctly? :-) Note that most JARs I see
> > on the net do not have any package versions nor JAR versions today, and
> > I see a lot of them. (there are licensing issues, but maybe Eclipse,
> > among others, can be used as a repository for jars so you can have a URL
> > point to the right lib, we might even support such a global JAR
> > repository from inside Eclipse, but that is another story).
> >
> > This would obviously only work for libraries that are not used for
> > communication. These libraries require a versioning model with backward
> > compatibility so that older and newer versions can keep communicating. I
> > am fairly convinced that a global namespace is necessary for these
> > "interface" libraries. It seems that a service registry for this purpose
> > has many qualities by encapsulating versioning problems.
> >
> > This probably needs some thinking/experience because I have not tried
> > this out, but it has been in my mind for some time. I foresee some
> > issues with (the evil) static methods but that can be worked out I
> > think. What do you think?
>
> I agree that this is an interesting direction to push. I'd like to see
more
> discussion of service models and how they could/should be intergrated into
> Eclipse.
>
> Jeff
>
> Side note: I suspect alot of the challenges we will face in Equinox will
be
> more related to understanding how (not) to program in a dynamic
environment.
>
>
|
|
|
Goto Forum:
Current Time: Fri May 02 02:05:50 EDT 2025
Powered by FUDForum. Page generated in 0.04268 seconds |
Home