PROPOSAL: Configuration Framework and Extensibility

[Wessel Dankers]

On 2002-12-10 20:47:23-0500, Francis J. Lacoste wrote:
> 1) perl is already tied very much in the framework. 

In the case of configuration this is not true; using shell scripts and
environment variables it was really a mix of perl and /bin/sh.
I also think this is one of the areas where interfacing with different
languages is important: debconf and linuxconf spring to mind.

> 2) Even if we use an XML format to express the configuration
> specification, it won't be practical to implement a PHP based
> configuration tool because we still need recode and test the 
> configuration library in PHP *and* perl.

But at least we can then add new configuration variables to all subsystems
at once, be they perl, PHP or another language. We would have no risk of
having the configspecs get out of sync, or making a programmer for a new
perl module learn PHP and C and produce a (probably inferior) identical
specification in those languages.

> 3) Besides, we didn't plan any time on our roadmap for the development 
> of non-perl based things.

True. Having these elaborate configuration mechanisms is definitely not the
main focus of Lire development. However, I fear the damage has already been
done :) I'm not sure if dropping the current specification system and
reverting to the more direct perl based system is substantially quicker
than just going forward and finishing what we have now.

> 5) If in 6 months or one year we want to develop a PHP based
>    configuration tool, we can still think of interoperability scenarios:
> 
>    - Export the API to PHP using a RPC mechanism like SOAP or XML-RPC

Hm, in my personal experience (which may be outdated) RPC is one of those
things which look nice on paper but are hard to get right and are flaky in
practice. But don't take my word for it, I'd hate to be spreading FUD.

>    - Add an export configuration specification to XML functionality to
>      configuration API.

Impossible if you're using perl functions to check validity of a
configuration.

> Bottom line, I don't think that the extra work needed to have a rich
> XML-based configuration specification format (especially for what is
> related to constraints) is worth it. I think that extra work could be
> better spent on other things like the integration of the reports
> configuration into the configuration process. 

Yes, but see point 3), above.

Kind regards,

-- 
Wessel Dankers <wsl at logreport.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20021216/10da99e7/attachment.bin