On Mon, Dec 13, 2010 at 9:49 PM, Pascal Rapicault <[email protected]>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_Startupis > 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: - Specify your own set of P2 repos to update from - Specify a different installation root (ie: for Citrix support) - Install a subset of the available Features rather than all of them. 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: - R1: The target platform - R2: The RCP Application plugin itself - R3: Features that implement real end-user functions 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: - We present a login dialog box and log the user in. - We call a web service and obtain the set of Features/Versions that this particular user user is allowed to access. - We call the updater. The updater installs just that set of Features/Versions and any dependent Features. It removes/disables all other Features. - If the update changed the running configuration we restart the platform. Otherwise we createAndRunWorkbench(display). 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. Regards, Dave
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
