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

[Olivier Gruber <ogruber@xxxxxxxxxx>]

Peter, Jeff,

Groups have value, but they have problems.
But I would like to make sure that we don't impose groups.
We may want to promote one model for
groups, through tool support in Eclipse for e.g., but I don't feel
we are in a position to impose a concept
of groups, nor that we have a good general solution.

First of all, even we would all agree
that groups have value, we have different grouping models.
At least, Eclipse features and MEG deployment
packages. I also know of Linux distribution
using RPM deployment to bring down plugins
(after all, this is just about downloading files).
I don't think we are in any position
to impose a grouping... You are right Peter, there is a lot
of semantics associated with grouping...
and it is mostly a concern for packaging and 
management tools. 

As we all remember, grouping introduces
many headaches, especially when sharing 
between groups are entertained. Installing
and uninstalling groups with non empty 
intersections is tricky. As far as I
know, no one has a decent and robust solution so far.
This is especially true because groups
never stay simple about sets of bundles...
Sooner or later scripting appears...
configuration data... etc...
It is the case for Eclipse and it is
the case for MEG Deployment Packages... 
Then groups get into fragments... and
optional downloads based on environment variables... 
because applications are formed out
of different  configurations in different environments... 
and this is not to consider different
offerings (different prices for different configurations).

So it is hard to reason about groups
in these contexts... to even predict if it can be installed or not.
Then again, you are right Peter... dependencies
between groups open up again the semantic 
question about flexibility (import-export
versus provide-require). Usually dependencies are more like
provide-require... but we need the import-export
flexibility... While for Java packages, we can 
rely on the specification versus implementation
semantics, this is no longer true for groups...

However, there are very good reasons
for not using bundles instead of groups...
Admin granule is usually much larger
than the runtime bundle granule...
You want to allow flexibility in the
configuration of a product or a product suite...
You want fine-grain ability to update...
fine-grain security control... 
fine-grain lifecyle and lazy activation...

All of which demonstrates that the runtime
modularity of a software does not match
very well the admin modularity of it...
or its provisioning modularity... 
Something that we should may think about
more... :-)

But here is my point, we may
allow groups... but it seems that we don't want to specify 
them in the OSGi standard. In fact,
I like that OSGi is mostly about runtime artifacts, and not
about provisioning. I would argue that
we don't want to force the adoption of a group semantics.
I would argue that we need to fit in
existing provisioning efforts... like JSR 124... or like OMA...

I would say that we need the following,
just for bundles, without talking about groups.
We need to have a provisioning infrastructure
for bundles, and bundle alone.
We need to be able to find where a bundle
can be downloaded from (technically easy
but not that easy in practice to put
in place...) We need to be able to override 
a bundle's definition of its dependencies,
 so to make it fit in a configuration 
when provisioning it (a flexibility
we don't have so far).
Above this layer, it should be easy
to build the notion of groups, if one wants to.

There is a lot to do at the level
of bundles alone... 
We have to consider extensibility there
for dependencies...
We already have import-export statements...
and require-provide...
We also have declarative services...
and extensions and extension points 
(I know some people that may not want
to deploy a plugin that provides extensions 
to non-available extension points)...

I like the JSR 124 approach... where
we talk about resources, providing and requiring capabilities.
The approach is extensible with the
ability to define new capabilities... with new matching rules.
It would be interesting to see if we
can model 

        -
RFC 79
        -
SCR
        -
extensions and extension points

What's missing I believe would be a
discovery infrastructure... 
mapping from capabilities to resources...

some of which will be OSGi bundles....
some of which may be other things.

I feel that OSGi provisioning needs
to fit in a larger story that allows to deploy not only bundles...
I don't feel like we will be able to
impose a unique grouping model... but through an open approach
we may allow OSGi to be a premier choice
for Java component models.

Groups are surely important, and I would suggest that we promote one model
through Eclipse
and a good tooling support... mostly
as a proof that we can built it on top of the bundle-level 
infrastructure... but I don't see why
we would want the provisioning infrastructure to be imposing 
a grouping model. Promote... but accomodate...
in other words... apply modularity and flexibility
to our own designs and architectures...
:-)

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/29/2005 08:58 AM Please respond to Equinox development mailing list

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

I think this is the discussion require-bundle versus
Import-Package
all over again ... :-)

a priori grouping will favor popular platforms until the extent that
there will be only one dominant platform because is too hard to
support all. (Law of increasing returns). E.g. Microsoft windows.
Without grouping I think it is easier for a management system to
compose a set that is needed, allowing third parties to provide the
glue components.

And I never understood why things are not just merged in a single
bundle if they really have to be together ...

The diversity of the embedded market requires imho a flatter model.
But then again, I guess I am only a theoretician :-(

Kind regards,

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

  


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