[
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
osgi-dev@xxxxxxxxxxxxxxxx.
Cheers
Niclas
