Re: Drivers and Data Source Names

Tim Bunce wrote:

> XXX need to consider handling of unknown attributes (ie version skew)
> and driver-private attributes. c.f. JDBC 4 wrapper pattern.

I believe,  it is basically sufficient to keep the old naming 
conventions, which I always found good. In particular the private_ stuff 
is something which I copied into various other areas.


> Separate client-side attributes from server/db-side?

No. Client-side attributes can be server side as well: Remember DBD::Proxy.


> Driver metadata should be accessible without loading db client api lib.
> That lets us cheaply and safely 'load' all drivers and at least query metadata.

Use a separate class? (DBD::Driver::MetaData?)


> 	dbi://host/driver/dbname
> 	dbi://foo.com/mysql/dbname

Uuuh, I doubt you're doing good here. I believe it's a good thing, that 
the driver can easily be parsed from the URI. Note, that JDBC URI's also 
start with the driver prefix.

What do you see as the advantage of being compliant with RFC2396?


> 	dbi:/SQLite/%2Fpath%2Fto%2Ffile

This is too much magic for me. If a driver needs that, okay, let him 
parse the URI that way. But is this actually something that the DBI must 
take care of?


> The plugin multiple driver managers can also implement name service lookups
> to map simple names (like "dbi:sales") into full DSNs via some external
> service like LDAP or even a ~/.dbi file. See JDBCs use of JNDI.

I may be getting you wrong here: What is the "driver manager"? Is it a 
new object, that you want to introduce? Note, for example, that JDBC has 
a single driver manager only. In other words, there is no need to 
introduce them. (Though I accept that they may be useful for things like 
connection pooling.)

JDBC's use of JNDI is totally different from JDBC URI's and should not 
be mismatched. Basically, the JNDI URI is a mapping from a separate URI 
namespace to arbitrary Java objects.  If anyone likes to implement a 
driver or a DBI subclass,  which maps URI's, he's free to do so. But is 
this actually something that the core has to support or consider?


Jochen