Heya, On Apr 10, 2008, at 22:22, Daniel Yokomizo wrote:
A couple of thoughts. 1. Why not use the usual Erlang approach for code update, using the loop for receiving messages and handling config updates, it seems cleaner and a better fit. This way you need only a single process to handle the config file format and notify the rest.
Can you elaborate on that for a bit considering that we're not all Erlang experts here :) Especially, what do you mean be "The Loop" and how is it conceptually different from what Damien proposes in his fourth and fifth paragraph? Do you mean to use the program's main run loop to do the job that Damien describes for a "configuration module"?
2. Also it would be simpler to have almost every config inside a CouchDB database, so you startup using the default config and the config process reads the database for the real config info and notifies the other modules of the actual values. With this in place it'll be easier to have other config formats in the future: just make some module that understands format foo and writes/reads it to/from couchdb. The config process will see the changes and propagate them.
Not sure if it matters where the actual data gets stored. New formats can be added to files as well as CouchDB documents, so one solution is as easy as the other. Or am I missing something?
IME it's better to keep config files away from the core of some application and let some external agent interpret the files and configure the application using an api.
Sorry to sound dumb again. Do you say keeping the handling of config files should not be in the CouchDB core? What is the core in this context? Would a configuration module that would deal with the config file considered "core" by you? Or would that describe that 'external agent' you mention? Thanks for your input! Cheers Jan --
