For http: lynx -dump | bearerbox /dev/stdin
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Malysh Sent: maandag 29 april 2013 18:44 To: Stipe Tolj Cc: [email protected] Subject: Re: [PATCH] Abstraction for config resources, allowing file, URL, pipe, etc. 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 > ------------------------------------------------------------------- >
