On 7/9/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
>
> At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
> >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 -
>
> Re-read that paragraph. It says 'not all being applicable at once'.
Yes - I realized that.
>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
I don't. The server name in IDS is not a host name or domain name, nor is it
a port number (so 2 is not applicable), nor is it the locally named socket
(so 3 is not applicable), nor is it the locally defined service (so 4 is not
applicable).
All of these are identified by, but are distinct from, the IDS server name.
There is a mechanism (configuration file) that hides all the gory details
from the user. Users should not need to know sordid details like port
numbers, or whether the host is on an IPv4 or IPv6 network, etc.
Further, within an IDS instance, there are multiple databases that can be
separately connected to - '[EMAIL PROTECTED]', '[EMAIL PROTECTED]', '
[EMAIL PROTECTED]', '[EMAIL PROTECTED]'. You must be able to specify the
database
within the server instance.
Now, in fact, server1 and server2 could be alternative names for the same
hunk of disk space, supervised by the same IDS instance but with different
connection properties - such as encrypted vs unencrypted - but that is
probably just too confusing. Equally, and more normally, server1 could be on
a wholly different machine from server2.
[Concrete example: I have many IDS instances running on my machine at work.
One instance has 4 names:
anubis_17, anubis_17_tcp, anubis_17_str, anubis_17_shm. The first two are
both network connections - albeit usually using loopback since I usually
work on the same machine. The third uses a STREAMS pipe; the fourth uses
shared memory. All allow me to connect to the same set of databases, which
includes 'sysmaster', 'sysutils', 'stores', 'logged', 'unlogged',
'mode_ansi'. Each of those databases has its own independent set of system
catalogs. I can connect to '[EMAIL PROTECTED]' or '[EMAIL PROTECTED]' and
edit the same data - it's the same database, identified by different server
names and different connection properties. I also have another IDS instance,
running an older version of IDS, with server names anubis_23, anubis_23_tcp,
anubis_23_str, anubis_23_shm - and the same set of databases, but only
because some of them are standard and the others I keep there to make
testing DBD::Informix easier. I also have an entry configured for a database
server called 'smartpts' that is based in Lenexa, KS - I work in Menlo Park,
CA - about 1800 miles away. I can run $db1 = DBI->connect('
dbi:Informix:[EMAIL PROTECTED]'); $db2 = DBI->connect('
dbi:Informix:[EMAIL PROTECTED]'); to connect to those databases. I can also, in
general, do distributed queries between the two databases without explicitly
connecting to the other. And note that I can switch between TCP and SHM
connections on the local machine (which is
anubis.menlo.ibm.com<http://anubis.menlo.ibm.com>)
simply by changing the server name - I don't have to do any other
modifications to the connection string.]
Please note that for Informix, the database name (optionally with server
name) is all you need to specify. (There's an environment variable that
specifies the default server name if you omit it.) Specifying a 'host name'
won't work; there is no mechanism for connecting by specifying a host name -
except as part of the configuration file. Specifying a port number (or
service name) won't work; there is no mechanism for connecting by specifying
a port number or service name - except as a part of the configuration file.
I'm sorry that life is more complex that you wish to recognize - but that is
how life is.
>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".
No - you don't seem to understand. The challenge-response protocol can ask
someone for the RSA key fob number this time, their mother's maiden name the
next time, their employee number the time after that, and nothing on the
fourth occasion. You cannot predict what the extra information requested is
going to be - so you can't provide the extra information in the initial
connection attempt because you don't know which extra information is going
to be needed. That's what provides the security - the unpredictability of
the question, so that it is hard to pre-programme the answer.
Don't get hung up on this - challenge-response authentication protocols are
not in everyday use in very many places, but they are likely to become more
prevalent in future. In particular, the RADIUS protocol (RFC2865 plus sundry
supporting RFCs) supports challenge-response. And the PAM (Pluggable
Authentication Modules) support it - look them up sometime.
>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.
Only if the decomposed form contains the information that is needed in a
form that can be used.
OK - bullet 10 says:
10. some other authorization credential, or channel encryption details, or
whatever else;
I ruled out 10a (some other authorization credential) as a way of dealing
with challenge-response protocols; it does not prevent it from being usable
in some circumstances. 10b is of some value - though IDS hides that
information from the average user (the same configuration file that defines
what the server means and how to connect to it includes the information on
whether encryption is to be used; another configuration file typically
defines the detailed encryption options). DBD::Informix won't be able to
accommodate arbitrary choices on encryption; both the client and the server
have to be set up compatibly, both expecting to use encryption.
That leaves, I suppose, 10c 'or whatever else'. If that is intended to be a
wholly open-ended set of options, then we can, if necessary, cover the
critical part of the IDS connection information in 'whatever else' - but it
feels kind of odd that the database name is 'whatever else'. The IDS server
- that I can live with DBI not handling; it can simply be regarded as a
funny part of the IDS database naming convention. So, as long as the rules
allow '[EMAIL PROTECTED]' as a valid name for a database, DBD::Informix can
hide
the server from the rest of DBI. But you must allow users to specify just a
database name and the driver name 'dbi:Informix:dbase' or '
dbi:Informix:[EMAIL PROTECTED]', or a segregated equivalent:
{Driver=>'Informix',
Database=>'dbase'} or {Driver=>'Informix', Database=>'[EMAIL PROTECTED]'}.
I note in passing that database names and server names can be up to 128
characters each; don't impose arbitrary limits there, either, though that
isn't part of the Perl philosophy so I don't expect it to be an issue.
Now, if some idiot tries to connect to IDS with connection information such
as {Driver=>'Informix',
Host=>'yucatan.example.com<http://yucatan.example.com>',
Port=>1526}, DBD::Informix will have to reject the connection attempt -
insufficient information. If {Database=>'[EMAIL PROTECTED]'} is part of the
connection string, DBD::Informix can ignore the extraneous matter, or reject
the connection attempt because the extraneous matter is irrelevant and
probably incorrect. Now, at one level, I neither know nor care whether a
database name as found in IDS is of any relevance elsewhere - it is of
relevance to the DBMS that I deal with. As such, DBI should be able to
accommodate it. If DBI won't accommodate it, it won't be because the
designers were not made aware of the issue. However, I believe other DBMS
can support multiple things called databases within the scope of a single
DBMS instance.
Your proposal does not contain one, arguably two, critical pieces of
information -- the Informix-style database server name and the
Informix-style database name. A single Informix host machine can be running
multiple instances of IDS. I'd like to be able to manufacture the necessary
background information for you - but I can't. The server name and the
database name are both needed, and are not covered explicitly by the items
on your list. It doesn't matter how much you try to bend it - the
information you are planning on providing does NOT include all the
information necessary to connect to an IDS database except under the
catch-all clause in item 10, which is not a satisfactory place for it to be
handled.
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.
Please - listen to me. I'm an expert on IDS. I know whereof I speak. I don't
have a mandate to make changes to IDS because of possible future
requirements from Perl and DBI. I regard the details you are trying to
expose as retrograde steps - however, if there was a need from our customers
for the retrograde setup, I'd support adding it. But I'm not getting any
pressure on that - there are many other much more important problems and
features to add.
The problem that I'm trying to get across to the people involved in the
design of DBI v2 is the same as the problem that I had to explain to back in
January. The model you wish to impose on every DBMS in the world does not
fit every DBMS in the world - there are real, practical, in-use
counter-examples which demonstrate that the way you (collectively - not you
specifically, Duncan) would like to be able to do it will not work for some
DBMS. I'm sorry that (a small portion of) the real world is raining on your
parade - but something has to give, and the bit that is still unfinished is
DBI v2 - IDS has been working the way it currently does for upwards of a
decade, and DBI v1 accommodates Informix quite adequately; I don't see any
good reason for DBI v2 to break it. IDS goes to lengths to conceal from the
people using it (as opposed to the administrators setting it up) all the
ghastly details you are revelling in exposing. Further, it not only conceals
those details, it uses some extra information that you've not yet accounted
for. No; you probably don't need to worry about the extra information - but
it is there and is hidden by the configuration file.
Please, please, please provide a mechanism that will work for Informix as
well as the other DBMS.
OK; I'll answer questions about what would or would not work for Informix,
and help design the mechanism. I'm not going to expound any more on the
basic problem - but I will vote against any proposal that cannot be managed
by Informix. And you can't say you were not warned.
--
Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.01 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."
