Re: Re[6]: [equinox-dev] OBR2

[Olivier Gruber <ogruber@xxxxxxxxxx>]

How does this discussion on OBR2 relate
to what SUN is doing for server-side modelling of services?

Can't remember the JSR though... but
I remember talking with SUN people at some of the OSGi meetings.
Peter, remember, we talked about this
about a year ago at your house, during a MEG discussion about deployment
packages...

With a generic framework for resources
providing and requiring capabilities. 
The server-side framework has a plug-in
approach where anyone can define its own capabilities and how to match
them... 
I am not saying that they have solved
it, I don't know enough about the current state, but the goals are very
similar and 
they have been working at this for quite
a while.

Just a thought...
Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center

Peter Kriens <Peter.Kriens@xxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx 09/25/2005 12:14 PM Please respond to Equinox development mailing list

To:        Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>         cc:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>         Subject:        Re[6]: [equinox-dev] OBR2

I think we agree ...

The repo metadata should have no semantic knowledge of its contents.
The requirements/capabilities should be generic. When you import you
translate the specific (import-package, require-bundle, scree=128x256,
etc) requirements to generics. This means that the repo does not need
to have semantic knowledge.

However, a group should be the result of a query and not explicitly
submitted to the repo. If you do that, you always end up in a
combinatorial explosion of groups. The diversity out there is so high
... which en then usually means only 1 configuration is supported.
Works maybe for Windows, but OSGi needs something more flexible imho
because portability is at the root.

Kind regards,

     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 <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

  


-- 
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