[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers

On Friday 31 March 2006 07:04, Alex Blewitt wrote:

> This is the key problem, for me. A package is an open-ended bucket, to
> which not only this bundle, but *any* bundle, can contribute classes
> to. It's an implementation facet. There's nothing to stop other
> bundles inserting (or attempting to replace) items in this package on
> a piecemeal basis. A bundle, on the other hand, is a closed collection
> of code that I can depend on as a black-box unit. A package is *not* a
> black box.

Sign and Seal.

> My mentioning of the Linux alternatives was another system that uses a
> way of providing a loose coupling between systems that can be replaced
> at run-time. 

AFAIK, Linux does not allow packages to be replaced at "runtime". Anything 
that is loaded, remains loaded. Perhaps "deploy-time" is a term more in 
analogy with OSGi.

> But it's not the same as services. An OSGi service can be 
> started or stopped independently of bundles that depend on it; they
> may not even be able to acquire a service, even though the package is
> there. On the other hand, if I have a bundle dependency, then I can
> guarantee that that bundle is started before mine is and will remain
> started for the lifetime of my bundle.

I am not sure what your reasoning is intended to lead to. It seems that you 
have a notion of how you want to do things (IMHO, based on how you have 
always perceived software) and that is fine. Please do what suits you the 
best,if not for any other reason than makes you feel it is the right way.

> That's why I suggested the idea of virtual bundles. They allow the
> same functionality as services, but without the potential problems.

Ahhh... Here it is.
1. They do not provide the same functionality. They may provide a 
functionality that contains some overlap.

2. Since I am not very fond of the coupling of RequireBundle at all, I should 
probably not take part in the argument.

3. I think your input will actually be a lot better received by the JSR-291 
Expert Group, as the JSR does not cover the Service layer. I suggest that you 
take the effort and publish a more official web page of what you have in mind 
than rabbling on this list ;o), and then post a pointer on