To me the danger of adding yet another abstraction ends up being an issue of having more layers to keep aligned as things evolve in one or the other, and thus more code and API surface. To be clear, the actual functionality you want to add is very useful but the API you are using to represent it is limiting and goes against a lot of efforts that have been going on to run multiple instances of p2 in the same system. Therefore if we just go with the API as you propose it, next thing you will know, you will have request to offer the possibility to specify an agent, tweak the restart policy, then a this or a that... and we will end up with something that will be almost like, but not exactly like PCO which will result in even more confusion. And on top of that you will have to add the methods for cases like those from Eugen (true usecase as well there).
In the end I think we are trying to resolve two problems in one shot: 1) Lack of functionality around sync'ing a p2 instance with a remote repository. 2) Ease of use of the API My proposal is to treat those separately: - The missing functionality is interesting and should be added. If I was to add that functionality just by itself, I would likely add it directly to the operations because this is where we expose these sorts of high level functionalities, and I would try to add the same support in the director.app. This would be a subclass of the InstallOperation that overrides the getProfileChangeRequest() to create a request that describes the expected final state. - Then separately if someone was coming to talk about simplify the p2 API, I would first try to understand how far from the Operation API is the desired state and then see how we can pave the way. For example: What about providing a factory that returned an API where you had pretty much just one or two method calls to do? like new InstallOperation(URI[] repos, IVersionedId[]).getProvisioningJob().schedule? For example, in one case there is an API to list the features to install, how would the caller of this new API get the elements to fill the list? I mean does he/she has to query the list of IUs from a repo? On 2011-02-09, at 10:35 PM, David Orme wrote: > Hi Susan, > > I'm open to considering making this code part of the operations API, but > right now have a hard time imagining it there. > > Right now, the code is basically a 300 line script (that happens to be > written in Java) that utilizes several Operations to get its job done. In > other words, it really feels to me like a layer of abstraction above > operations. > > I've looked at the code that Eugen and Scott wrote and their API is almost > exactly what we've proposed as well. > > Actually, theirs is probably a more proper abstraction layer on top of > Operations and ours takes their idea one step further and really specifically > enables some RCP use-cases. (Theirs is designed as a remote-management API > for Equinox-based server containers.) > > So my own thinking is that we should try to take into account our own > use-cases and theirs as much as possible. > > And to my thinking, that doesn't necessarily make sense as part of the > Operations API. > > However, I welcome attempts to convince me otherwise. :-) A code snippet > showing how one would use one of our APIs, but reimplemented using > Operations, to update an RCP application might be helpful to make it easier > to imagine what you're considering. > > > Regards, > > Dave Orme > > > On Wed, Feb 9, 2011 at 11:10 AM, Susan Franklin McCourt > <[email protected]> wrote: > I agree that being part of the ProfileChangeOperation hierarchy would be a > good thing. Whereas InstallOperation will only do the updates forced by > requirements, you are talking about wanting to do other selected updates. I > think this can easily be accommodated in that hierarchy. > > As far as simplifying the number of concepts to use. It strikes me that most > of what you are talking about is simplified constructors that create the > operation by assuming an RCP setup (getting the agent and services from the > running profile.) So you could add those constructors for simplicity and > still retain the operation concept. > > This would have several advantages in my opinion: > - a remote administrator would surely want to use this concept to update a > system other than "self" profile. The operation would let them do this, > otherwise you have to start adding those very same concepts into this new API. > - operations can feed into the UI, so if a more advanced use case required > the user confirming which updates/installs were needed, you could just open a > wizard (or make minimal change to existing wizards). > > I realize the purpose of your proposal is to get away from the > variables/concepts that pollute the RCP mindset, but my experience is that > someone will say, "it's just like your simple API but I want to pass an agent > in." or whatever. The operation hierarchy's purpose was to capture the > "80/20" use cases and I agree that the "synch profile with a controlled repo" > is one that is definitely needed... > I like the idea of SynchronizeProfileOperation or something like that. > > susan > > <graycol.gif>David Orme ---02/09/2011 07:23:18 AM---On Tue, Feb 8, 2011 at > 3:04 PM, Pascal Rapicault <[email protected]>wrote: > Think I got my second > > From: David Orme <[email protected]> > To: P2 developer discussions <[email protected]> > Date: 02/09/2011 07:23 AM > Subject: Re: [p2-dev] Proposal: Simplified installer/updater. > Sent by: [email protected] > > > > > On Tue, Feb 8, 2011 at 3:04 PM, Pascal Rapicault <[email protected]> wrote: > Think I got my second question answered :) > The second install, I would call it "makeItSo" :) > > :-) > > The question I still have is, why would not those be cast in terms of > ProfileChangeOperation (in the sense, inherit from there), maybe with a > additional helpers? > > Because what we actually do is an UpdateOperation followed by an > InstallOperation. Our testing showed that this is what we needed to perform > a full synchronization. > > But if inheriting from PCO is a better choice, we could consider that. > > A question of my own: > > I don't think we've tested yet how to make sure that a Feature that is no > longer used gets removed from the running platform. > > In our first API, if a Feature or Bundle is removed from all of the available > repositories (and they are all reachable on the network), then it should be > removed from the running platform as well. > > In our second API, the collection of IVersionedIds should completely define > the provisioned platform for the user. > > Do we need to do something special to disable all Features not referenced by > one of those IVersionedIds (either in the set of P2 repos, or in the > parameter list)? > > > Dave > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
