A couple quick points.
On Sat, Feb 18, 2012 at 1:09 AM, Philip Rhoades <..hidden..>
wrote:
Roderick,
On 2012-02-18 09:16, Roderick A. Anderson wrote:
Philip Rhoades wrote:
</snip>
It looks like the choices are: Config::General, Config::Std, and
Config::Tiny, YAML and JSON but why don't you just put the data
into a
PG table? - if localhost and port 5432 are not being used, then
presumably the person is competent enough to change the config
table
appropriately and if the install was faulty or fails then the
accounting is not going to work anyway so the config info is
irrelevant.
If it isn't localhost and port 5432 then how does LSMB connect to
the
database to know which host and port to use? :-)
Perhaps I wasn't clear enough - in the great majority of cases,
localhost and port 5432 will work fine and a "config.sh" or a create
config table facility in a larger script is all that is needed. In
the
cases where that won't work, then presumably the person who is
managing
the existing installation will be clued up enough to manually edit
the
"config.sh" script appropriately and change variables to correspond
to
the actual port and server name.
I think Rod has a valid point though.
To retrieve the config information, the system needs to know where to
connect to and what port. I dont know about you but I have customers
who do have instances which span machines, and even multiple db
clusters for testing changes before they go into production. The
connection information really does need to be stored somewhere that
the application can then use to retrieve it.
So that means some sort of a config file. And once we go that far,
isn't it simpler to just store installation-specific config info in
that file?