[dtp-connect-dev] Committers Meeting Notes - 2005-10-26

[rcernich@xxxxxxxxxx]

Here are the notes from the connectivity sub-project's weekly committers
meeting.

Attendees:
Rob Cernich (Sybase)
Brian Fitzpatrick (Sybase)
Larry Dunnel (IBM)
Gilles Roux (IBM)
Linda Chan (Actuate)

Discussed basic requirements for drag and drop functionality within the
data source explorer.  Consensus was reached on the following:
1.  The DSE will not provide any specific drag and/or drop functionality
beyond what is provided by the navigator framework.  Individual consumers
have the ability to add their own drag/drop handlers by extending the
navigator framework.
2.  In the event certain drag/drop functionality is required of multiple
consumers, we will consider adding that functionality to the DSE directly.

Discussed requirements and design for connection management within the
connectivity project.  Here is a summary of the discussion.

Rob gave a brief overview of the existing connection management
functionality in the connectivity project.  There is a
ProfileConnectionManager class that implements a simple reference counting
mechanism for connection sharing.  There is a property on the
IConnectionProfile used to determine whether or not a profile is in a
"connected" state.  This is used as a hint to consumers that they should
open a connection to the profile (basically, this is used to synchronize
the connection state of the profile when it appears in multiple views).
The dis/connect() methods on IConnectionProfile are used to send
notifications to consumers that have registered an IConnectListener in
addition to updating the connected state of the profile.  Connection
objects are loosely related to the connection profile they were created
from (i.e. you can navigate from a connection to a connection profile, but
not from a connection profile to a connection).

Larry gave a brief overview of the existing RDB connection management
functionality.  There is exactly one connection associated with each
connection profile (note, a connection in RDB is synonymous with a
connection profile; here connection refers to a JDBC connection and
connection profile refers to a defined "connection" in RDB ).  Consumers
can navigate in both directions between a connection and its related
connection profile.  Larry also stated they have a requirement to be able
to clone existing connections (e.g. to support transaction isolation).

The team then discussed various options for implementing connection
management.  Some of these options were:
Enhance the existing connection management functionality and integrate this
directly with the connection profiles themselves (i.e. force consumers to
create connections through the connection manager and add capabilities to
the connectivity framework for creating non-shared or cloned connections).
This is the approach the team decided to take for the initial DTP release.

Use the Java connector architecture for connection management.  This may be
an ideal solution, however we decided that it was a bit overkill for the
requirements we needed to meet within DTP.  (We would be using a server
side implementation of the Java connector architecture, complete with
connection pooling, etc.  This was much more than we need for a client side
GUI.)  We did decide to revisit this idea at a later time as there are some
requirements for using the connectivity layer in a server type environment
(e.g. BIRT).

Action Items:
Rob - Create bug reports for tracking implementation of connection
management.