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
