[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[10]: [equinox-dev] OBR2
|
We are talking to much ... :-)
1. My needs today are a simple discovery model so www.osgi.org
can be the access point for a large set of bundles. OBR2 seems to have
most of what I need and looks awfully simple. Groups can be supported by
requirements/provides I think (Require bundle and fragments model
are mapped to reqs/provides).
2. We should separate the client discussion from the discovery model.
3. I need to know ASAP what we must absolutely add to OBR2 XML schema
(for example the license seems to make sense and maybe optionality
on the requirements).
4. I really want to host such a file after the world congress on www.osgi.org.
5. Richard, I could not find the XML you currently use. Could you give us
a URL or send some examples?
Kind regards,
Peter Kriens
JM> It certainly is a flavour of that. Perhaps many of the same arguments apply?
JM> The basic problem is that you can componentize the world but
JM> then you have thousands of little pieces to manage. Following
JM> dependency chains at runtime is cool but there is a need for
JM> repeatability both on the producer and consumer sides. Grouping
JM> is meant as an abstraction layer that allows people to talk at a
JM> higher level .
JM> Keep in mind that I am not suggesting that groupings be
JM> inviolate. Groups are in effect a cataloging system that allows
JM> people to define sets of things that go together. You and I can
JM> both define sets that include some or all of the same bundles.
JM> I am not sure what you meant about the third party glue code.
JM> As for merging bundles, it is a good point and a question
JM> that one should always ask when defining a bundle - "does this
JM> bundle always ship with some other bundle (and vice versa)?" If
JM> the answer is yes, then you ought to reconsider the proposed
JM> decomposition. In any event, there may be valid reasons to keep
JM> them separate.
JM> Jeff
JM> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM> 09/29/2005 07:58 AM
JM> To
JM> Jeff McAffer/Ottawa/IBM@IBMCAcc
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>Subject
JM> Re[8]: [equinox-dev] OBR2
JM> I think this is the discussion require-bundle versus Import-Package
JM> all over again ... :-)
JM> a priori grouping will favor popular platforms until the extent that
JM> there will be only one dominant platform because is too hard to
JM> support all. (Law of increasing returns). E.g. Microsoft windows.
JM> Without grouping I think it is easier for a management system to
JM> compose a set that is needed, allowing third parties to provide the
JM> glue components.
JM> And I never understood why things are not just merged in a single
JM> bundle if they really have to be together ...
JM> The diversity of the embedded market requires imho a flatter model.
JM> But then again, I guess I am only a theoretician :-(
JM> Kind regards,
JM> Peter Kriens
JM>> For the most part. I believe that explicit groups are
JM>> necessary. It is natural to group things and then group the
JM>> groups etc. Doing this with queries is possible but ends up being
JM>> roundabout. Your point about explosion is valid but queries don't
JM>> solve the problem. For example, who is going to manage the
JM>> queries? How do I tell you about my group? Do I send you my
JM>> query? What if someone adds something that matches the query but
JM>> I did not intend for that to be part of the group? How do you
JM>> compose multiple query-based groups to make a composite group?
JM>> Groups can be done in a way that allows you to have your
JM>> groups and me to have mine. We can share the group definitions if
JM>> we want but do not have to. If shared they can be inthe repo as
JM>> first class enties. They (perhaps) can be versioned and express
JM>> dependencies of their own.
JM>> Jeff
JM>> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM>> 09/25/2005 11:14 AM
JM>> Please respond to
JM>> Equinox development mailing list
JM>> To
JM>> Jeff McAffer/Ottawa/IBM@IBMCAcc
JM>> Equinox development mailing list
JM>> <equinox-dev@xxxxxxxxxxx>Subject
JM>> Re[6]: [equinox-dev] OBR2
JM>> I think we agree ...
JM>> The repo metadata should have no semantic knowledge of its contents.
JM>> The requirements/capabilities should be generic. When you import you
JM>> translate the specific (import-package, require-bundle, scree=128x256,
JM>> etc) requirements to generics. This means that the repo does not need
JM>> to have semantic knowledge.
JM>> However, a group should be the result of a query and not explicitly
JM>> submitted to the repo. If you do that, you always end up in a
JM>> combinatorial explosion of groups. The diversity out there is so high
JM>> ... which en then usually means only 1 configuration is supported.
JM>> Works maybe for Windows, but OSGi needs something more flexible imho
JM>> because portability is at the root.
JM>> Kind regards,
JM>> Peter Kriens
JM>>> Just to clarify what I after is not having to author two sets
JM>>> of metadata. From a repository USER's point of view I have a
JM>>> bundle, I add it to the repo. I need a bundle, I query the repo
JM>>> and get the thing I need/want. When adding a bundle to the repo
JM>>> the repo itself should interrogate the bundle and find any
JM>>> dependencies.
JM>>> There is a challenge in that there may be dependencies that
JM>>> cannot be detected. For example, we have this in our Help setup
JM>>> where help needs an appserver. Typically Tomcat is supplied but
JM>>> there may well be others. You would not want to spec help to
JM>>> depend on Tomcat. If we were using services then you would spec
JM>>> Help to need the webapp service. Perhaps when we have declarative
JM>>> services that will be a possibility but there will still be such
JM>>> scenarios where the public contract implied by services is not
JM>>> appropriate and alternative mechanisms (e.g., the extension
JM>>> registry) are used.
JM>>> Grouping bundles is an interesting notion that solves this
JM>>> issue as well as allows function producers to explicitly declare
JM>>> sets of bundles that go together. A bundle group can simply be
JM>>> viewed as a bundle that aggregates the constituent parts. However
JM>>> it is actually represented it is just a unit that exports the
JM>>> union of the exports in its contents and imports/required the
JM>>> union of its prerequisites. etc.
JM>>> Expressing or representing these capabilties and requirements
JM>>> in an an open, extensible way is goodness.
JM>>> Jeff
JM>>> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM>>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM>>> 09/23/2005 12:16 PM
JM>>> Please respond to
JM>>> Equinox development mailing list
JM>>> To
JM>>> Thomas Watson <tjwatson@xxxxxxxxxx>cc
JM>>> Equinox development mailing list
JM>>> <equinox-dev@xxxxxxxxxxx>, heavy@ungoverned.orgSubject
JM>>> Re[4]: [equinox-dev] OBR2
JM>>> Good idea, but I assume it can be used to generate the meta data?
JM>>> I think this is an example where the generic requirements capability
JM>>> model shines. We will have lots of dependencies that need to be
JM>>> modeled. Modeling them semantically in the repo format will make the
JM>>> repo format a major spec work undertaking.
JM>>> Kind regards,
JM>>> Peter Kriens
TW>>>> Can we use SCR's component XML definition for service
TW>>>> dependancies? Even if the bundle does not use SCR directly can we
TW>>>> still use this schema to define service dependancies? I would not
TW>>>> want to define a whole new schema for this.
TW>>>> Richard, are you subsribed the the equinox-dev mailing list?
TW>>>> If not, please do so we don't have to keep cc'ing you on the
TW>>>> mails :)
TW>>>> Thomas Watson
TW>>>> Pervasive Development
TW>>>> Phone: 512-838-4533 Tie: 678-4533
TW>>>> tjwatson@xxxxxxxxxx
TW>>>> equinox-dev-bounces@xxxxxxxxxxx wrote on 09/23/2005 08:34:11 AM:
>>>>> Agree ... if it is not in the manifest, we can't generate it. But it
>>>>> is nice to populate a repo with only the data from the manifests and
>>>>> get reasonable results.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>> RSH> Peter Kriens wrote:
>>>>>
>>>>> >>It absolutely MUST be possible to generate the metadata from the
>>>>> >>manifest.
>>>>> >>
>>>>> >>
>>>>>
>>>>> RSH> Well, it is not possible given the current state of bundle manifests to
>>>>> RSH> generate all repository metadata. For example, there is no way to
>>>>> RSH> generate service dependencies.
>>>>>
>>>>> RSH> If someone invents a new capability/requirement pair, there will be no
>>>>> RSH> way to generate it either.
>>>>>
>>>>> RSH> For the standard package/module-related stuff, we can generate them from
>>>>> RSH> the manifest.
>>>>>
>>>>> ->> richard
>>>>>
>>>>> RSH> _______________________________________________
>>>>> RSH> equinox-dev mailing list
>>>>> RSH> equinox-dev@xxxxxxxxxxx
>>>>> RSH> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>
>>>>>
>>>>> --
>>>>> Peter Kriens Mob +33633746480
>>>>> 9C, Avenue St. Drézéry Tel +33467542167
>>>>> 34160 Beaulieu, France Tel +15123514821
>>>>> Tel +33870447986
>>>>> AOL,Yahoo, Skype pkriens ICQ 255570717
>>>>>
>>>>> _______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>>>
JM>>> --
JM>>> Peter Kriens Mob +33633746480
JM>>> 9C, Avenue St. Drézéry Tel +33467542167
JM>>> 34160 Beaulieu, France Tel +15123514821
JM>>> Tel +33870447986
JM>>> AOL,Yahoo, Skype pkriens ICQ 255570717
JM>>> _______________________________________________
JM>>> equinox-dev mailing list
JM>>> equinox-dev@xxxxxxxxxxx
JM>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>>
JM>> --
JM>> Peter Kriens Mob +33633746480
JM>> 9C, Avenue St. Drézéry Tel +33467542167
JM>> 34160 Beaulieu, France Tel +15123514821
JM>> Tel +33870447986
JM>> AOL,Yahoo, Skype pkriens ICQ 255570717
JM>> _______________________________________________
JM>> equinox-dev mailing list
JM>> equinox-dev@xxxxxxxxxxx
JM>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM> --
JM> Peter Kriens Mob +33633746480
JM> 9C, Avenue St. Drézéry Tel +33467542167
JM> 34160 Beaulieu, France Tel +15123514821
JM> Tel +33870447986
JM> AOL,Yahoo, Skype pkriens ICQ 255570717
--
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
Tel +33870447986
AOL,Yahoo, Skype pkriens ICQ 255570717
