> > Suppose someone's creating a GUI app (Perl/Tk, etc.) in which the end
> > user fills in the server, port, user, password, and database into a
> > screen of some sort. The back-end app will have to know how to
> > translate that into a DBI connection string. And it's probably not
> > reasonable to make the user understand the details of how to make a DBI
> > connection string in this case.
>
> Can I point out that you seem to be assuming the MySQL/Pg model of how
> servers, ports, databases, users and passwords work.
>
> This all has no meaning to SQL*Net (Oracle), SQLite, ODBC and probably
> other databases, too.
Every time ive had to use ODBC ive had to provide these things. (Pretty
much.) Likewise with Sybase and MS SQL Server.
But I don't really see the point of the objection. Either you don't have to
provide some part of this information, in which case presumaly the DSN
thingee should DTRT and just ignore those fields it doesnt need. If they
need additional information then I supposes it's a bigger issue. OTOH, Im
not so sure how much bigger. It would seem that its reasonable to expect the
DSN thingee to be queryable so you can say:
my %fields=DSN->driver_needs_fields('DBD::Sybase');
And then find out which fields you need to ask for (and maybe even what
regexes they should match to be considered valid :-) ( port=>/^\d+$/,
server=>/^[\w.-]+$/, .... )
Note im talking about a hypothetical module, I havent had time to review the
actual proposed module yet. My point is just that functionality like what
was described sure sounds useful to me.
yves
