[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re[6]: [equinox-dev] OBR2

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