On Sat, 2005-07-09 at 01:22 -0700, Jonathan Leffler wrote:
> Oh drat - not the DBI connection string discussion again!
> On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> > 5. All details used to construct a connection handle should be
> > completely decomposed rather than shoved into an ungainly "data
> > source". Examples of what should be distinct (not all being
> > applicable at once) are: 1. the DBI driver module to use; 2. the
> > internet server IP address or domain name and port; 3. the locally
> > defined server device socket; 4. the locally defined service (eg,
> > ODBC or SQL*Net) name; 5. the file system file name; 6. the file
> > system directory name; 7. some other detail if any for fully in-RAM
> > databases; 8. the authorization identifier / user name; 9. the
> > password; 10. some other authorization credential, or channel
> > encryption details, or whatever else; 11. what kind of database or
> > what database product is being used, if known. If the DBI driver
> > talks to a client-configurable DBI proxy server, then, it should be
> > possible to nest a set of the above settings (eg, as a hash-ref) as
> > one part of the main settings given to the proxy client.
> > 
> Only 1, 8 and 9 (driver name, user ID, password) apply to Informix databases 
> - and you've missed out the other bit that applies - the database name, and 
> optionally database server name hosting it (either 'dbase' or '[EMAIL 
> These are not the same as 2, 3, 4, 5, 6, 7, 10, or 11, and I can't think how 
> any of them (except perhaps 10) could be applied to an IDS connection.

There are certainly database-specific things to be worked around.  An
improvement to the current DSN scheme would be a URI, as discussed in
the past.  The leading dbi: on every DSN is redundant, so a URI might
look like this:

driver://user:[EMAIL PROTECTED]:port/instance

> Oh, and if you're going to enhance the connection, please ensure you cover 
> challenge-response protocols (where you send an initial username/password 
> and the authentication server comes back with a question such as "what is 
> the number on your RSA key fob at the moment", and the hapless user has to 
> type that information in, and the connection management code has to deal 
> with this - callbacks and the like.

Seconded, with request for support of SSL client certificate


Reply via email to