Re: DBI v2 - The Plan and How You Can Help

Sam Vilain wrote: 
Maxim Sloyko wrote:

But this is not the point. The point was that usage of some file with passwords by *DEFAULT* is not the way to go, IMHO. It raises more problems than it solves. 


Can you give an example of such a problem that wasn't already there?

Just to be clear, the file would only need to contain passwords if the
DBD requires them.

Sam.

May be it is just me, but having a bunch of config files is not very good. Config files should be for program, not for separate modules of that program. They are hard to manage, when there are many of them. Besides, DBI is a high level abstraction and it is not a good idea to tie it to some file. May be it is better to let DBD:: modules choose? For example, you can pass some parameter to the driver in connect string, which tells it, where passwords are stored. Something like this is impleneted in DBD::Oracle, where you can just pass 'sid' parameter to the driver, the rest configuration parameters (except passwords and usernames) are read from oracle config file, from the section to which that sid parameter points.

I don't mind if you implement this ".dbi" feature though, I just want it to be invisible :) i.e. don't check this file, if I explicitly supply username and password (this is obvious, right?) and show some warnings if don't. Say, make a connect parameter "use_dot_dbi", which is zero by default.

--
Maxim Sloyko
.

Relevant Pages

  • RE: DBI v2 - The Plan and How You Can Help
    ... Sam Vilain wrote: ... > Maxim Sloyko wrote: ... > May be it is just me, but having a bunch of config files is not very ... > string, which tells it, where passwords are stored. ...
    (perl.dbi.users)
  • Encryption Question
    ... We have some .dlls that we have written that use config files to store ... posting I asked for some suggestions for encrypting the passwords. ... suggested DPAPI and after some research this sounded like a good idea. ...
    (microsoft.public.dotnet.general)