What passing in configuration information means is that the base application can request the same configuration information in whatever means it wants to from the user (commandline parm, hardcode, config file, whatever). For example, if you had a dot-rc file (e.g., ~/.yourapprc) where this info was stored, the user would tell you once, and never have to worry about it again.

No matter what, the user will likely have to tell you something. Interrogating all known databases on the system (which may include TB-sized databases that are remote) might be seen as uncouth by some ;-) So, whether they tell you during the Makefile.PL process (bad idea - makes it difficult to automate the install unless it's a commandline parm) or via a config file (easy to automate), they tell you something.

Separating out your configuration from the app's configuration is also a good thing. You may write all this code to read a config file, but then find out that the app is using a different config file, of a different format (e.g., YAML or XML). Then you'll just look clunky. By forcing the app to pass in your configuration information, you'll allow the app to define its own configuration format and file, and you just get to piggyback on that.

Note that it's very rare that an abstraction layer completely removes the app's care about which backend is used. What an abstraction layer is supposed to do is limit that care to a single line - which, as in this case, might be passed in via config file. I've worked with many abstraction layers, and I've never seen one smart enough to know what I want without me telling it first ;-)

Good points, and much appreciated.

My grand vision (doesn't everyone have a Grand Vision?) is to have a collection of applications which all use this abstraction layer. So I'm waffling between a "suite" config file or a separate abstraction-layer config (file, or at make time).

I agree that randomly probing for potential back-ends is less than polite :-) (and no-one has implemented Mind::Read, yet), AND presumably whoever is installing will know what they want to use....

I hadn't thought of the "automating the install" issue with an interactive make.

Gak. /me mentally runs in circles.

-- WARNING: You are logged into reality as root.