Hi, just came across this patch again and find it unnecessary complicated. Why we have to differentiate pipe and file and why we have to tell config_read which type of config to read?
For pipe: $ cat config | bearerbox /dev/stdin The same as above foe the file. And for HTTP just define filename as HTTP URI. That's it. No modifications in the boxes needed because config module will handle this transparently. Alex Am 19.10.2012 um 05:34 schrieb Stipe Tolj <[email protected]>: > Hi list, > > I have abstracted the gwlib/cfg.[ch] module in order not to handle simply a > 'config file', but a 'config resource', which then can be either of: > > - a config file > - a config URL, retrieving the config via the HTTP body > - the stdin pipe, allowing to pipe in a config > - a data block itself, interpreted as config > > Now, to demonstrate the effect, here are some sample ways on how Kannel's > daemon can be then started: > > $ bearerbox > > will look for 'kannel.conf', as it does today. > > $ bearerbox smskannel.conf > > will open the local 'smskannel.conf' file, parse and expand it, as it does > today. > > $ bearebox http://host/smskannel.conf > > will HTTP GET to the URL and pull the config from the HTTP response body. > > $ cat smskannel.conf | bearerbox pipe > > will instruct bearerbox to read in the config from the stdin pipe. > > Ok, sounds sweet, right? But is there more? Yes, there is. Due that the > gwlib/cfg.[ch] module is abstracted on these "types" of resources for the > config, we can mix them using the 'include = <resource>' statement. > > I.e. I can have a local smskannel.conf that includes a remote URL config > part, or I can fetch a remote URL config block, but refer again to local > config files, etc. > > Now you may ask what's this used for, you have been living quite fine with > the normal local config style, or even have sync'ed configs via rsync to > achieve HA setups? > > Yes, sync'ing the filesystem is a way to make "remote changes" for a Kannel > worker node. But I wanted something that is even more simple, like the HTTP > URL call fetching of the config. > > This allows a "controler node" to instruct how the Kannel "worker nodes" will > operate. Meaning, to which SMSCs they connect, which sms-services they need > to obey, etc. > > It makes things simply more flexible, especially when you start to look at > large scalability, HA and LB issues. > > The patchset can be found at URL: > http://www.kannel.org/~tolj/patchsets/cfg/gateway-cfg.diff > > NOTE: The user's guide part is still missing, I'll make sure this gets into > the patchset before committing. > > Reviews, comments, votes welcome. > > Stipe > > -- > ------------------------------------------------------------------- > Kölner Landstrasse 419 > 40589 Düsseldorf, NRW, Germany > > tolj.org system architecture Kannel Software Foundation (KSF) > http://www.tolj.org/ http://www.kannel.org/ > > mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org > ------------------------------------------------------------------- >
