Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
DTP Ganymede Connection Wizards Discussion
Contents
Introduction
The purpose of this page is to serve as a coordination point for community discussion about the DTP connection creation wizards. This page is not a substitute for Bugzilla entries, newsgroup/mailing list discussions, or other communication channels and policies used by DTP. Rather, it is intended as a jumping off point where discussions happening in a variety of places can be collected.
Goal
Ultimately, we hope that the discussion will result in actionable items completed during the DTP 1.6 ("Ganymede") release. Whether this is possible or not of course depends on the outcome of these discussions, so no specific commitments are made based only on the existence of this page or other discussions.
Note: We are not considering (at present) replacement of the existing connection wizards and underlying connectivity frameworks. There is a segment of DTP adopters who find this technology flexible and compelling, and would be negatively impacted by its removal. Instead we are considering (as a first guess) the delivery as an alternative of an additional set of connection wizards that are more suited to adopters expressing concerns discussed here. That is, we will strive to meet the requirements of both segments by making DTP configurable for specific use cases.
Plan
- [12/7/07, complete]: Initial page creation
- [12/11/07, pending]: DTP PMC review and planning discussion
(More steps will be added when determined.)
Background
The design of the DTP connection wizards (and associated driver template definitions) has been the subject of discussion on a number of occasions. In this section we link to these original discussions and in the next section we will summarize the main points.
Bugzilla Entries
Wiki Pages
Newsgroup Threads
Summary Discussion Points
In this section we'll attempt to summarize the main points expressed in the other reports. This is especially crucial, since it will define the scope and priority of work done, and will be refined as necessary going forward.
Too Many Steps
Probably the most common complaint: It takes too many steps to define a connection. Ideally, the desire is for a one-page connection wizard.
Provide Reasonable Defaults
Reasonable guesses (which can be changed by the user) should be provided whenever possible. This is especially true for the connection name.
Create Default Driver Instances
The notion of "driver template" is a bit different from one would think when considering, for example, templates used by word processing programs. In the case of a word processor's template, a document can be created directly based on the template. Driver templates, however, are more like template-for-templates (meta-templates?) that require first the creation of an instance of the template type, and then use of that template instance for connection creation. While the additional layer gives flexibility, the terminology is confusing and we should provide default driver template instances to remove the extra step. (Note that these template instances can be edited and deleted by users if they wish.)
Too Many Drivers
Currently (in the driver templates) there are multiple versions listed for various types. These should be consolidated and listed only by type, with the version being specified by a template property.
Confusing Terminology
Labels and instructions should be specific to the connection type being created (rather than generic), and use commonly accepted terminology whenever possible.