Bugzilla – Full Text Bug Listing
| Summary: | [ui] More feedback on what's installing | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | bokowski, bugs.eclipse.org, cvgaviao, david_williams, digulla, gunnar, irbull, jan.wloka, jeffmcaffer, jtk499, mauromol, pascal, pwebster |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 330338 | ||
| Bug Blocks: | |||
|
Description
Stephan Herrmann
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. |