At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
On 7/4/05, Darren Duncan
<<mailto:[EMAIL PROTECTED]>[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 -
Re-read that paragraph. It says 'not all being applicable at once'.
and you've missed out the other bit that applies - the database
name, and optionally database server name hosting it (either 'dbase'
or '[EMAIL PROTECTED]'). 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.
I think that 2 thru 4 cover this, though I used more generic language.
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.
I mentioned those generically in 8 thru 10; the latter is "some other
authorization credential etc".
So, as was discussed emphatically and exhaustively (in January 2005
in dbi-dev under 'Proposing an API for the extension for simplifying
database connections'), this is not readily going to fly with the
existing DBMS - specifically, not with IDS. Closed-source DBMS are
*not* necessarily going to adapt to meet the needs of Perl and DBI.
You can argue that's their loss - you may even be right. But you'll
be limiting the acceptability of Perl + DBI in some respects.
You'll also be annoying the hell out of me if you can't define a
connection string that will work with Informix (I'm not too worried
about the challenge-response stuff, though Informix can handle that).
If a database only accepts input in string form, then the DBI driver
can generate one out of the decomposed information it is given. No
trouble here, really; no trouble at all. The whole point of a DBI
driver is to map between the DBI interface and how the database
product natively does things. It is true that some things can only
be done by changing the database product itself, but other things can
be done in the DBI driver, with no support from closed-source DBMS
necessary.
-- Darren Duncan
