(New page: {{Back To|name=DTP Main Page|href=Data Tools Platform Project}} ==Introduction== The purpose of this page is to serve as a coordination point for community discussion about the DTP connect...)

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. 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.

+

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.

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.

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.