Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DTP Connectivity Project Committers Meeting Minutes: August 20, 2007"
(→Attendees) |
(→Minutes) |
||
| Line 15: | Line 15: | ||
== Minutes == | == Minutes == | ||
| + | From Larry... | ||
| + | 1. Support for pre-populating the connection UI with driver definitions. In our products, we don't want the user to have to manually instantiate driver definitions for the common drivers. | ||
| + | |||
| + | 2. Common UI for selecting existing connections. Since many database tools require the user to specify which connection they want to use, it is desirable to have common UI so that users have a consistent experience. The UI should allow for filtering of the existing connections as it may required by a feature to only display connections that have a certain attribute. It should also be extendable so that a feature might display properties for the connection beyond a default set. The UI should be implemented such that feature developers can extend the UI class and use it in wizards, dialogs, etc. | ||
| + | |||
| + | 3. Best practices for prompting users for creating new connections, selecting existing connections and prompting the user for authentication information. We should probably create a code sample that demonstrates the preferred way for developers to implement support for allowing the user to create new connections, prompting them for authentication information so that the connection can connect to the server, and select existing connections within the context of a wizard and demonstrates the features of the common connectivity UI components. This way we can ensure consistent user experience across features. | ||
| + | |||
| + | 4. *Be able to inject from a runtime instance of a connection at startup to populate a profile in the DSE. Possible this may be dropped, but need to look into it. May play into the repository code. | ||
| + | |||
| + | From Linda... | ||
| + | |||
| + | 1. Filtering needs work. There are several BZ entries on this, but we need to make it much more extensible. Perhaps split out catalog-loader (SQL-level) filtering from client-level (viewer-level) filtering. | ||
| + | |||
| + | 2. Provide extensible encryption capabilities for exporting profiles. | ||
| + | |||
| + | From Brian... | ||
| + | |||
| + | 1. Focus on usability and extensibility. | ||
== Attendees == | == Attendees == | ||
Latest revision as of 17:34, 20 August 2007
Agenda
After today's PMC/Team Lead meeting, we have a couple of things to discuss...
For 1.5.1 --
- September 12 is DTP 1.5.1 RC build
- Release projected at September 28 for DTP 1.5.1
For Ganymede -
- Resolution of Discouraged Access warnings in Connectivity where possible
- Connectivity Ganymede High-level Project Plan by 10/1, draft by 9/17
- Begin determining what Connectivity features/BZ entries should go into Ganymede
Link to PMC/Team Lead meeting minutes [1]
Minutes
From Larry...
1. Support for pre-populating the connection UI with driver definitions. In our products, we don't want the user to have to manually instantiate driver definitions for the common drivers.
2. Common UI for selecting existing connections. Since many database tools require the user to specify which connection they want to use, it is desirable to have common UI so that users have a consistent experience. The UI should allow for filtering of the existing connections as it may required by a feature to only display connections that have a certain attribute. It should also be extendable so that a feature might display properties for the connection beyond a default set. The UI should be implemented such that feature developers can extend the UI class and use it in wizards, dialogs, etc.
3. Best practices for prompting users for creating new connections, selecting existing connections and prompting the user for authentication information. We should probably create a code sample that demonstrates the preferred way for developers to implement support for allowing the user to create new connections, prompting them for authentication information so that the connection can connect to the server, and select existing connections within the context of a wizard and demonstrates the features of the common connectivity UI components. This way we can ensure consistent user experience across features.
4. *Be able to inject from a runtime instance of a connection at startup to populate a profile in the DSE. Possible this may be dropped, but need to look into it. May play into the repository code.
From Linda...
1. Filtering needs work. There are several BZ entries on this, but we need to make it much more extensible. Perhaps split out catalog-loader (SQL-level) filtering from client-level (viewer-level) filtering.
2. Provide extensible encryption capabilities for exporting profiles.
From Brian...
1. Focus on usability and extensibility.
Attendees
Brian Fitzpatrick
Larry Dunnell
Linda Chan