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 ;-)

In reply to Re^3: Module configuration for user vs. developer by Tanktalus
in thread Module configuration for user vs. developer by bibliophile

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.