Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^2: Module configuration for user vs. developer

by bibliophile (Parson)
on May 31, 2006 at 15:32 UTC ( #552832=note: print w/replies, xml ) Need Help??

in reply to Re: Module configuration for user vs. developer
in thread Module configuration for user vs. developer

I'm of two minds about this. On the one hand, it seems reasonable that an app pass in some config information.

On the other hand, in an ideal world the app wouldn't care which backend is being used (which would be one of the strengths of the abstraction layer).

Clearly I need to think about this some more :-)

-- WARNING: You are logged into reality as root.
  • Comment on Re^2: Module configuration for user vs. developer

Replies are listed 'Best First'.
Re^3: Module configuration for user vs. developer
by Tanktalus (Canon) on May 31, 2006 at 15:46 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://552832]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (2)
As of 2018-05-28 03:51 GMT
Find Nodes?
    Voting Booth?