Hi, On Wed, Nov 30, 2005, Stipe Tolj wrote: > The issue about config directives that are used explicetly for Mbuni should > go also into the direction of an add-on API config mechanism, in order to > let add-on extentions configure and build without the explicite need on > patching Kannel's source tree.
That would be good. > Something like: > $ cd gateway > $ ./configure .... --with-add-on=../mbuni > then Mbuni's configure would be triggered after Kannel's configure runs and > Kannel would proive a mechanism to "incorporate" the "new" config > directives into it's gwlib/cfg.c module. That would be bad. That seems to expect the Mbuni sources are available when building a Mbuni aware Kannel. That's particularly bad for creating packages, and if Kannel and Mbuni have separate release cycles... unless you plan to merge both projects in one big source tree. > At least an approach, if you come up with a better one, please shout, we're > open for ideas in this section. Please correct me if I'm missing something, but here's what I think is happening currently: [ Kannel source ] - Kannel tree has a config file grammar which describes the possible sections, the possible parameters of each section, and the type of the parameters - a parser is generated at build time to parse the Kannel configuration - at run time, some additional checks are performed [ Mbuni ] - Mbuni patches the grammar file to add its own sections, parameters in these sections, and the type of the parameters - Kannel needs to be rebuilt, but you only need Mbuni's Kannel patch to build (not the full Mbuni source) and the resulting Kannel can be run without Mbuni installed - binaries from Kannel and Mbuni are built with a Kannel lib which can parse the configuration What you'd like to do is something in the lines of keeping more grammar definitions from different projects in Kannel, and including them conditionnally. I'm not sure that's the way to go, for multiple reasons: - this whole discussion sounds like reinventing the wheel (whats more basic than parsing a configuration file?), I'm surprized that Kannel isn't based on some general library providing the service (I can only think of license issues, or maybe portability?) - having a grammar *and* runtime checks seems a bit of duplication to me, especially since the grammar isn't very rich (eg IP addresses are defined as OCTSTR(), URLs are defined as OCTSTR(), hostnames are defined as OCTSTR()), and hence renders the grammar maintenance a bit useless - having to rebuild Kannel each time a third party config items change is quite bad (each time one Kannel based project releases, Kannel needs a rebuild, think of package distributions) Again, this is from an external eye, so I hope you will correct the mistakes in my remarks, and in the following suggestions: - you could use a very simple syntax, and a very stupid parser, which simply ignores things it doesn't know about, and move all checks at runtime, this permits implementing "foo is deprecated" parameters, and this lets each application bark about things it knows about - you could use a schema system, similar to the current one, but with a runtime component based schema validation, for example "GConf" applications drop a schema describing their configuration parameters, types, and default values, and then request values to the gconf library - you could pass whole configuration file sections to dynamic modules or let the modules extend the syntax when they're present at runtime (eg what Apache does), but this is complicated and heavy to implement - you could use another configuration library, if you find one that fits your license, and is available on the platforms you target, and use its model At all rates, please keep configuration handling quite separated from Kannel and make sure third party modules can build out of tree. Cheers, -- Loïc Minier <[EMAIL PROTECTED]> _______________________________________________ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
