|Re: [p2-dev] Proposal: Simplified installer/updater.|
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.
David Orme ---02/09/2011 07:23:18 AM---On Tue, Feb 8, 2011 at 3:04 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx>wrote: > Think I got my second
From: David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 02/09/2011 07:23 AM
Subject: Re: [p2-dev] Proposal: Simplified installer/updater.
Sent by: p2-dev-bounces@xxxxxxxxxxx