Thanks for your feedback, Pascal. Responses inline. On Tue, Dec 14, 2010 at 6:58 PM, Pascal Rapicault <[email protected]>wrote:
> 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? > The Thread is simply used to wait until it's time to run the update. When the actual update runs, we schedule a Job. We return the Thread object so that when the app shuts down it can notify() the thread so it can shut down gracefully. Why? Nobody on the team could come up with an argument that we needed anything more complicated than a standard Java Thread.currentThread.sleep(bunchOTime) to schedule a recurring thing to happen at some time in the future. Are we missing anything? . > Note that we have similar code in org.eclipse.equinox.p2.updateChecker > Yeah; I've noticed that moving onto P2, a lot of our code can just go away. Which makes me happy. :) We originally coded all this against 3.3. > 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? > I wasn't aware of P2 shared install support. That quite possibly could allay our concern. I just found http://wiki.eclipse.org/Equinox_p2_Shared_Install#Current_Approach and will ask if I have questions. Thanks. > 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. > Thanks for confirming this. We just discovered this experimentally and were wondering if this P2 wonder could possibly be real. :) > 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. > > That's a nice idea too. Thanks! Dave
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
