Skip to main content

[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



Back to the top