[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Executing a P2 traverse query

On Mon, Dec 13, 2010 at 9:49 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:
See comment embedded.


(a) When an application starts up, it checks for updates and automatically downloads/installs them.
How similar to http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application#Headless_Updating_on_Startup is your code?

The code you reference is really good and helped us to get going quickly in P2.  I really appreciated having it.

The goal of our proposed API is to simply add one more layer of abstraction on top of the current P2 API where there is a 1:1 mapping between APIs and common update use cases.

For example, synchronizing the current installation with a set of P2 repos whose addresses are stored in a Java properties file is one line:

* Runs an update operation using the update site defined in the config
* service (by key org.eclipse.e4.enterprise.installer.UPDATE_SITE) within a
* progress dialog so that a user can see updates are occurring
* @return UpdateStatus represent success/failure and containing an
* exception if something failed
public UpdateStatus updateWithProgressDialog() throws InstallError

Similarly, kicking off a background thread that checks for updates every X minutes is one line of code:

* Runs an update operation in a background thread (via an Eclipse Job)
* every number of minutes that you specify pulling the update site to poll
* and the download root directory (where downloaded features/plug-ins are
* placed) from the configuration service or will be in your install
* directory if not specified
* @param minutes
* Check for updates every x minutes
* @return Background thread uses to schedule update jobs
public Thread updateOnScheduleInBackgroundThread(int minutes) throws InstallError

The three parameters I mentioned before are the ones we find people wanting to change most often:
So that's what we let people tweak.  The most complicated version of our application level API is:

* Runs an update operation using the update site, download root directory, and set of provisioned features passed in within a
* progress dialog so that a user can see updates are occurring
* @return UpdateStatus represent success/failure and containing an
* exception if something failed
public UpdateStatus updateWithProgressDialog(final URL[] updateURL, final File downloadRootDir, final Set<FeatureVersionedIdentifier> featuresToProvision)

Self-updating RCP apps tend to live in a world where there is a tightly controlled list of P2 repos that the application accesses, and those repositories collectively define exactly one application.  It's cheap to set up an additional P2 repos, and it's profitable to partition an application so that its Features are referenced across multiple repositories.  For example:
Depending on the size of the application, R3 might be split too, but hopefully this communicates the idea.

I'm not sure what P2 terms are yet for downloadRootDir, but I'm guessing that this has something to do with P2 Profiles?  In Update Manager, this specified a root directory where we would create your install site(s).  The purpose is to enable installations on Citrix or *nixes where the installation directory might not be writable; this we have to support putting updates somewhere else.
p2 hides any concept of location except on creation of the installation. You should dump this parameter.

This is a pretty deep concern.  Like I said, Citrix on Windows and the *nixes pretty much require us to have this.

How much effort would be required to make this work?

See class VersionedId.

Cool; thanks.

featuresRequested is basically our query API.
What are you trying to achieve by doing the traversal ?

Sometimes you have one application where different users are permitted to use different Features based on their security level. 

Rather than download all of the Features and have code that turns functionality on and off in the UI, it's better (and more secure) not to download the code to begin with.  If the Feature isn't installed in the user's Platform, they will find it much more difficult to access functions that they are not permitted to access.

We implement this by making the following customizations to Application#start, BEFORE the Workbench is started:
So basically we've discovered that it can be really profitable to use Features/updates as a coarse-grained entitlements engine.

Hope this helps.  We appreciate and value your thoughts.