I'm talking about the mechanism by which anything that comes from the Application-Content header would be isolated while all other computed dependencies from the resolver would be shared. This may be a good default behavior, but I don't think it's sufficient. I'd like to discuss a possible way to solve the problem globally.
On Fri, Feb 19, 2010 at 14:46, Alasdair Nottingham <[email protected]> wrote: > I'm sorry but I'm not sure what you are reluctant to introduce as a > result it is difficult for me to comment. > > On 18 February 2010 21:24, Guillaume Nodet <[email protected]> wrote: >> Fwiw, I'm a little reluctant to introduce such a mechanism given I >> think it does not support all the use cases. >> If you consider the application as a composite with external >> dependencies, what we want to do is be able to draw the boundaries >> between what should be inside the composite and what should be >> outside, but also what needs to be imported and what's need to be >> exported. Exporting is quite important since you may want to have >> services and packages defined by the application being visible to >> other applications. >> >> I think we need to support having applications being completely shared >> (including the application content) or completely isolated (including >> all the dependencies). But we should look for something both powerful >> and easy to use for the common cases. >> >> What about using osgi headers such as Import-Package / Export-Package, >> Import-Service / Export-Service for that. >> If a package that is a dependency is in the Import-Package list, this >> means it should come from outside the composite, else the bundle >> should be installed inside the composite and isolated. Same for >> services. >> >> On Tue, Feb 16, 2010 at 18:21, Alasdair Nottingham <[email protected]> wrote: >>> I think perhaps this is where a subsystem is different from an >>> application, but I'm a little out of my depth here having not been on >>> the subsystem calls or having read the RFC/RFP. >>> >>> Alasdair >>> >>> On 16 February 2010 16:20, Guillaume Nodet <[email protected]> wrote: >>>> IIRC, we had some discussions around that on a subsystems conference call. >>>> I think the outcome was roughly that we may want to support three modes: >>>> * all shared >>>> * all private >>>> * mixed content >>>> >>>> It should be quite simple using a global flag somehow which could be >>>> overriden for some specific bundles. Shared would mean to install in the >>>> main framework, while private would mean that the bundles would be >>>> installed in a composite bundle. >>>> >>>> I also think we need the same kind of flags at package and service >>>> level so that one >>>> can control what services and packages will be visible from outside >>>> the composite >>>> bundle. >>>> >>>> The approach you propose has the limitation of not being able to >>>> deploy an application >>>> in an all-shared environment IIUC. >>>> >>>> >>>> >>>> On Tue, Feb 16, 2010 at 14:28, Alasdair Nottingham <[email protected]> wrote: >>>>> I haven't been following the subsystem work in the alliance as closely >>>>> as you (Graham Charters has, but is on vacation this week so it'll be >>>>> interesting to see his thoughts when he gets back next week), but >>>>> based on my understanding I also see applications as a specialisation >>>>> of subsystems, and I do think that aries should support both >>>>> applications, and the more general sub-system solution. I also see a >>>>> strong affinity between an application and a composite bundle. >>>>> >>>>> On the subject of applications being self contained I have a slightly >>>>> different view, in fact I was going to send an email today about >>>>> contributing some improvements. I'll try to explain my thoughts here >>>>> (let me know if it needs a different discussion thread). I'm going to >>>>> talk about this in terms of composite bundles, because that best >>>>> describes what I am trying to achieve. >>>>> >>>>> The Application-Content of an application describes the isolated, or >>>>> core, content of the application. When an application is installed a >>>>> composite bundle is created and the bundles in the Application-Content >>>>> are installed into the composite. The application may need additional >>>>> packages or services that are not provided by the core content. This >>>>> is also possible and bundles that provide those packages are installed >>>>> outside the application composite and can be shared with other >>>>> applications. >>>>> >>>>> This is not reflected in our current implementation, but I was going >>>>> to propose adding it in. I was not planning on changing the >>>>> Application.MF, it would still have the application-content as it is >>>>> today, but when you call createApplication on the >>>>> AriesApplicationManager we generate a deployment.mf that is used when >>>>> install is called (we call out to a resolver to do this). This >>>>> deployment.mf currently contains a Deployed-Content header which >>>>> contains all the bundles in Application-Content, but ties them down to >>>>> a specific version. In addition to doing this I was going to add a >>>>> header named "Provision-Bundle" which denotes bundles that are needed >>>>> to support the application-content. These bundles would be installed >>>>> into the host framework and be shared with other applications. >>>>> >>>>> So the Application-Content in the Application.mf is isolated content, >>>>> but the Deployment.mf contains additional shared bundles that are >>>>> required to support the application. >>>>> >>>>> What do you think? >>>>> Alasdair >>>>> >>>>> On 16 February 2010 11:21, David Bosschaert <[email protected]> >>>>> wrote: >>>>>> Yeah, maybe we need to tidy up the terminology a bit and come to >>>>>> agreement on that, I think Guillaume's clarification helps. >>>>>> >>>>>> In my opinion it would be nice if Aries could provide both models. The >>>>>> shared subsystem building block one as well as the more isolated >>>>>> application one. Since I tend to think about Applications as a >>>>>> specialization of a subsystem it should be possible to do this quite >>>>>> naturally. >>>>>> >>>>>> Just my thoughts, >>>>>> >>>>>> David >>>>>> >>>>>> On 15 February 2010 22:21, Guillaume Nodet <[email protected]> wrote: >>>>>>> Are you talking about nested framework instead of subsystems ? >>>>>>> Subsystems are currently defined by RFC 152 and nested frameworks by >>>>>>> RFC 138. >>>>>>> >>>>>>> My understanding is that applications as they stand are meant to be >>>>>>> self-contained (or mostly) and isolated, >>>>>>> whereas subsystems can be considered more as building blocks with >>>>>>> sharing capabilities >>>>>>> >>>>>>> The way applications or subsystems can be isolated could be done using >>>>>>> nested frameworks or manifest rewriting for example. >>>>>>> >>>>>>> On Mon, Feb 15, 2010 at 22:58, David Jencks <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> On Feb 15, 2010, at 1:34 PM, Guillaume Nodet wrote: >>>>>>>> >>>>>>>>> Aries applications model is quite similar to the subsytem model being >>>>>>>>> discussed in the OSGi EEG. >>>>>>>>> I'd like to think that subsytems are more generic than applications, >>>>>>>>> or said another way, that applications >>>>>>>>> are specialization of subsystems. Subsystems allow reference to other >>>>>>>>> subsystems, scoping, etc... >>>>>>>>> >>>>>>>>> I'd like to see how we can make both fits together. I guess the first >>>>>>>>> question to solve it whether we want >>>>>>>>> to keep applications the way they are, without advanced features >>>>>>>>> provided by subsystems such as >>>>>>>>> sharing / scoping, dependencies on other subsytems, etc... >>>>>>>>> >>>>>>>>> Once we've answered that, we can think about the way we want to >>>>>>>>> support >>>>>>>>> both. >>>>>>>>> >>>>>>>>> Thoughts ? >>>>>>>>> >>>>>>>> >>>>>>>> My point of view.... perhaps shared by no one else.... is that an >>>>>>>> application would be deployed or installed into a particular >>>>>>>> subsystem, but >>>>>>>> that several apps and plain bundles can all be installed into a single >>>>>>>> subsystem. I'm thinking of an application as a way to deploy a set of >>>>>>>> bundles at once, where the "maven-like" dependencies aren't specified, >>>>>>>> and >>>>>>>> where the framework has a way to resolve the osgi dependencies into >>>>>>>> maven-like dependencies. >>>>>>>> >>>>>>>> I don't think this idea is expressed in the current code in any way. >>>>>>>> >>>>>>>> thanks >>>>>>>> david jencks >>>>>>>> >>>>>>>>> -- >>>>>>>>> Cheers, >>>>>>>>> Guillaume Nodet >>>>>>>>> ------------------------ >>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>> ------------------------ >>>>>>>>> Open Source SOA >>>>>>>>> http://fusesource.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> Open Source SOA >>>>>>> http://fusesource.com >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alasdair Nottingham >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>> >>> >>> >>> -- >>> Alasdair Nottingham >>> [email protected] >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
