Comment embedded.
On 2010-12-14, at 5:08 PM, David Orme wrote:
>
> [...]
> 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
Out of curiosity, why not use a job? Note that we have similar code in
org.eclipse.equinox.p2.updateChecker
> 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.
I do not have any knowledge of the Citrix environment. What is special
about it?
How does that relate to the support for shared installed that we have
in p2?
>
> 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.
Unless I'm missing something and assuming that you can detect what
needs to be installed for a given user on each feature, then the use case you
are describing does not require the traversal.
Just identify the feature you want to install, pass it to the install
operation (or create an IU referring to the features you want to install),
done. The install operation will actually figure out everything that needs to
be installed (and will actually do some sort of traversal).
Also as a point of interest, and if the roles to feature mapping is not
changing too much, you may be able to identify the roles by provided
capabilities in the IU representing the feature.
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
