Community
Participate
Working Groups
Inspired by bug 316362 I'm thinking of more transparency at the UI about what a provisioning operation will actually install. p2 is at a point where it automatically solves various issues behind the scenes without the user needing to worry, and I like the convenience of it. At the same time various issues of security and trust should be considered. The user has to decide which installs s/he considers safe, but at the time being the available information may be insufficient for this decision. Some pieces that might be important (incl. some that are already supported): - what repositories are being used to download from? (see bug 316362) - what additional software is being pulled in via indirect dependencies? - which unsigned artifacts are being installed? - which artifacts are being replaced by a patch feature? - what modifications to my installation will be performed at installation time (p2.inf stuff)? some of these are trivial like setting a larger perm gen space, others are more delicate like installing adaptor hooks. - specifically when an adaptor hook will cause byte code weaving detailed info about those effects are of interest The size of this list (may still be incomplete?) makes me wish we could find a generic solution. In order to reconcile information availability with convenience I'd suggest a hierarchical model, which lets users choose how deep they want to drill into this info before confirming a pending install. Some users may be content with "you have 3 security alerts at level 'intermediate' or below" and immediately confirm installation. Others may need to really see the bits that will be installed and modified before they can make this decision. Unfortunately, not all information is available at the same point in time. After reading meta data and before requesting artifact downloads: - e.g.: repositories used, indirect dependencies being pulled in After download of artifacts: - e.g.: unsigned artifacts, requested touchpoint actions After restart: - e.g.: byte code weaving I am interested in cooperation on these issues, because Object Teams is doing several of those things that users would like to be able to confirm (or reject). We already made efforts towards transparency in the About dialogs (which display what bundles are affected by bytecode weaving). But I would like to put my cards on the table already at the time of installing. And I'd love to see this closely integrated with the framework to make for a consistent UI.
In http://blog.objectteams.org/2010/10/lets-talk-straight-with-our-users/ I suggested a concept preliminarily called "install capabilities", which could be outlined as follows: In order to be able to provide relevant information to the user in a uniform way (rather than scattered over arbitrary points in time), I propose to extend the p2 metadata with declarations of what install capabilities an artifact requires. For some information (e.g., touchpoint instructions) this would be redundant and one has to balance uniformity against redundancy. The cool thing about such declarations in the metadata is: this could unify things that are directly controlled by p2 with others like load-time weaving. Based on these metadata a complete list of required install capabilities can be presented to the user for confirmation before any bits are installed. (Including a uniform model to provide an abstract overview with options of drill-down, as not to overwhelm users with unsolicited detailed information). The runtime should furthermore check that no installation utilizes capabilities which it has not requested from its metadata. For things like touchpoint actions p2 itself would be in charge of this checking. But some checks would need to be delegated downstream. For this to work, I envision a mechanism like extension points to be added to p2 metadata. E.g.: OT/Equinox provides support for load-time weaving, but in order to hook into Equinox it uses touchpoint actions for modifying config.ini. The install capability of installing adapter hooks could be requested with a record containing the following pieces: - request to install the adapter hooks - declaration of a new type of install capability ("OT/Equinox weaving") - name by which clients may request this weaving capability - name of a validator class that will be used by the framework for checking that only declared weaving will ever be performed. The validator would be part of the OT/Equinox implementation, extending the framework with new validations. - perhaps an xsd for data that clients shall provide as parameters to a request for use the weaving capability Users would confirm this in two steps: - confirm the OT/Equinox adapter hook (if confirmation is not given *no* OT/Equinox weaving will be allowed) - confirm individual requests to weave into particular plug-ins as requested by client plug-ins using OT/Equinox I'm aware that this is only a very rough sketch, which I'll be happy to further refine once there's sufficient feedback. Is anything towards this direction already present/planned in p2? I'll try to setup a BoF at ESE for further discussing these issues. Please join us if you have any comments.
I agree that some of these things would be nice enhancements, however I'm having problems to imagine a sane user model.
By talking to lots of folks about this during Eclipse Summit Europe I learned two things: - many are concerned that this feature would bloat the UI with yet one more question everybody will always answer blindly (just as licence dialogs :) - there are many cool plug-ins that are currently sweeping lots of issues of this kind under the rug. I've summarized my current thinking in the wiki at http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Capabilities Feel free to edit. Note that the proposal could actually obsolete the unpopular unsigned-jars dialog, which would be subsumed by the new feature. Since at this point it is not obvious whether the community will actually embrace a solution to this problem (although many of those I talked to acknowledged it as being an issue) I suggest to start by implementing only a subset, like: Only specific install capabilities - singed/unsigned jars (should be easy?) - internal access, if this information can easily be extracted from the builder - p2 touchpoint instructions, either just any, or when installing an adapter hook (this being an important back door) Only all-or-nothing confirmation in the UI accompanied with a static report (i.e., no drill-down nor selective confirmation). Once we have this in place it should be easier to discuss with developers of other plug-ins having some dirt under the rug, too. And we should then also start to observe whether any consumers actually care.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
