Hi, I don't really see how it should work. Each config option have different needs and handling. Could you please try to provide some pseudo code that shows how it should/would work?
Stipe Tolj wrote: > Hi list, > > I have some good input on extending Kannel's config handling abilities: > > Currently we have several needs for a config value list, some examples: > > group = smsc > ... > accepted-smsc-id = "A;B;C" > > group = sms-service > ... > aliases = "key2;key3;key4" > > group = smsbox-route > ... > shortcode = "1111;2222;3333" > > so, all of these are either of type word-list or id-list, semantically > it's a semicolon seperated list. For some parts we have defined > foobar-regex config directives to handle PCRE/regex for a more simple > definition. > > The idea now is to create a more generic construct for this, which handles > 3 (maybe more?) different ways for any "list-type": > > foobar = "A;B;C" > foobar-url = "http://somewhere/foobar-list"; > foobar-regex = "<the regex expression>" > > so users can *CHOOSE* which way they prefer. And we handle the processing > of the list "transparently" to the logic that requires the list from the > config sections. > > I like this concept of abstraction here. Since we would encapsulate the > plain, -url and -regex handling to the scope of gwlib/cfg.{ch] and the > other calling modules simply pull for the list. > > Thoughts? > > ------------------------------------------------------------------- > 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 > ------------------------------------------------------------------- -- Thanks, Alex
