in reply to Where to store configuration information?

As always: it depends; there is no single answer that will be "right" in all cases.

Will everyone load these applications from a single network-based source (then you can have a single network-based configuration) or are these applications run from each user's box (then the configuration should probably be local too, esp. if they should still run without network access)? Perhaps you can implement a central repository with a local fall-back in case of network outage?

Can you split general configuration settings from user settings, or should they all be in a central repository?

Does the configuration contain items which must be kept secure or items which must be managed centrally because they are likely to change without prior notice?

Can you trust your users not to hack their local settings?

So many questions, so many different answers, so many different solutions. And remember TIMTOWTDI!

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

  • Comment on Re: Where to store configuration information?

Replies are listed 'Best First'.
Re^2: Where to store configuration information?
by Sue D. Nymme (Monk) on Aug 15, 2010 at 15:39 UTC

    Yeah, I figured there's no One True Way :-)

    The applications are run from various network locations, so I can assume that the user will be connected to the internal network. There aren't very many per-user preferences; mostly it's application configuration items, such as "where does this app find its database, and how does it connect?".

    There are definitely secure configuration items, such as database passwords. I can trust that the users aren't going to use network sniffing tools or password crackers (I think!), but I wouldn't want the data to be accessible in plaintext or in an easily-readable database location.

    Perhaps I should use a centrally-located configuration file that has some sort of basic encryption on it...