Hi, Dave. I see what you mean, it's a matter of whether you see it as a layer above, or just a factory/constructor that defaults all the parameters of an operation. I think both points could be argued, I just think that people will find your API useful and then want to tweak "that one little thing" which will make the layer look more and more like operations.
Today we have
new InstallOperation(session, collectionOfIUs); // install some
IU's
and
new UpdateOperation(session); // update everything in the profile.
Yours and Eugen's API seems to want to simplify the following:
- session is implied as the session with the services of the running
profile, vs. being a different agent
- you want to specify the URI's in the API rather than add them to
the manager beforehand or create a ProvisioningContext
- I'm not sure how progress monitoring is handled
- you don't want to "drive" the operation's "resolve" and "perform"
steps (we have two steps/jobs so the user can intervene and handle errors.)
So why not just have the API be
IStatus result = new ProfileSynchronizeOperation(someURIs).run();
or
IStatus result = new ProfileSynchronizeOperation(someURIs,
collectionOfIUs).run()
This seems as simple as what you propose, but by being implemented as an
operation, allows others to:
- set the session (if different than running instance)
- resolve/run in two different steps if user should intervene
- plug into the UI
- pass in progress monitors
susan
From: David Orme <[email protected]>
To: P2 developer discussions <[email protected]>
Date: 02/09/2011 07:35 PM
Subject: Re: [p2-dev] Proposal: Simplified installer/updater.
Sent by: [email protected]
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
Inactive hide details for David Orme ---02/09/2011 07:23:18 AM---On Tue,
Feb 8, 2011 at 3:04 PM, Pascal Rapicault <pascal@sonatDavid 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
<<inline: graycol.gif>>
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
