[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Bundle directories
|
Peter Kriens wrote:
I did not mean that the discovery should "detect", but once connected
to the OSGi repository, you must be able to learn about all other
repositories. I.e. the repositories can be a connected in a mesh.
I see. That is OBR's approach.
RSH> I would still argue for no server at all, since it raises the cost of entry.
I like the idea, but the disadvantage is that it does not scale. We
are currently discussing to make an OSGi hardware evaluation kit which we'd
like to make as small as possible. It would be nice if the client
could be very small. Then again, maybe we can have a 2 pronged
approach where that class of device has a management system which
preprocesses. (One of the recruited evangelists is interested
in making open source with the support of his company, so that might
be combined).
I don't find the optimization argument as compelling as the low entry
barrier argument. You could create some caching mechanism for the
metadata files.
OBR is very close in what I envisioned (with what I understand of the
capabilities and reqs model). Though authentication and maybe local
cache needs to be adressed for Jeff's extra needs.
Authentication is not too interesting for me, but I understand why
people would want it. Local caching does make sense.
Richard, can you give a short intro to how OBR will work with the
capabilities and requirements? I.e. how does it work with fragments,
optional requirements, require bundle, etc.?
Currently, it doesn't work with those, per se. It does, however, provide
[in beta] a capability/requirement model that could be used to model
them. For example, a bundle could provide a "host" capability and other
fragments could require that "host" capability. Similarly, a bundle
could provide a "bundle" capability another could require that "bundle"
capability.
The tricky part is dealing with special semantics, for example,
fragments may be optional or they may be many of them.
My thought here was to still follow a simple, generic approach and use
additional cardinality metadata (like in SCR or SB) to capture optional
or aggregate semantics. The benefit of doing this is that it could then
also work for "service" capabilities.
I don't have this last part implemented, however, it is just in my head.
-> richard
