[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Proposal: Simplified installer/updater.

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
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();
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


Inactive hide details for David Orme ---02/09/2011 07:35:51 PM---Hi Susan, I'm open to considering making this code part of theDavid Orme ---02/09/2011 07:35:51 PM---Hi Susan, I'm open to considering making this code part of the operations API, but

From: David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 02/09/2011 07:35 PM
Subject: Re: [p2-dev] Proposal: Simplified installer/updater.
Sent by: p2-dev-bounces@xxxxxxxxxxx

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.


Dave Orme

On Wed, Feb 9, 2011 at 11:10 AM, Susan Franklin McCourt <susan_franklin@xxxxxxxxxx> wrote: _______________________________________________
p2-dev mailing list

GIF image