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.