Brian J. Murrell wrote:
> [ I hope nobody minds the cross-posting but I think this is getting very
> relevant to both lists ]
> On Sat, 2003-06-28 at 22:49, Jamie Cameron wrote:
>>Since Libconf is just a Perl API, you certainly could use it for
>>writing webmin modules with no problems.
> Indeed, and were I writing modules, I would most likely use it.
>>However, from looking at that
>>page it seems that their parsers cannot yet handle any config format
>>that webmin cannot also, so there would be no big gain from using it yet.
> Are there generic parsers in Webmin? I thought there were generic "read
> file, module parses" type functions but I did not see anything that
> packaged up a config file as nicely as Libconf within the base Webmin
Each webmin module has a library of functions for parsing the config
files that it manages, which are used by the module's CGI programs.
For example, the Users and Groups module's useradmin/ subdirectory
contains the file user-lib.pl , which has functions for converting
Unix users to and from Perl arrays and hashes.
These functions can be called by any module that wants to perform user
management - for example, the standard Change Passwords module uses
them instead of containing it's own code for editing /etc/shadow.
So it seems to me that Libconf is very similar to one of the existing
'layers' in Webmin, though probably better written and more suited to
use by stand-alone programs.
>>As they add more parsers it would make sense to create webmin modules
>>that are just 'wrappers' around those parsers though, so that all the
>>work the Libconf team has done can be made available in webmin as well..
> That is mainly the reason I brought it up here. I would like to see the
> Webmin project and the Libconf project benefit from each other's work
> and resources.
> But rather than having Webmin wait for Libconf to have parsers for all
> of the different (kinds of) config files out there, it would be
> beneficial to both projects to see Webmin embrace Libconf sooner (ASAP
> even) than that and promote writing Libconf parsers for all new modules.
> That way people who are developing new Webmin modules and writing
> parsers anyway, benefit both projects at once at no additional cost. In
> fact it could become a cost savings, even in the near future because if
> a new module writes a generic parser because it's file(s) are a generic
> format, the next module to use that format doesn't have to write a
> I have not looked that deeply into it but I don't see why Webmin could
> not embrace Libconf ASAP and keep existing modules with their own
> parsers just as they are (until somebody migrates them at some point --
> which may even be never) and develop new modules with Libconf.
That would be possible, but I would be reluctant to add such a major
module dependency to Webmin.. Currently one of it's nicest features is
that you can install it on any system running Perl, and no extra
modules are needed (unless you want to turn on SSL).
Of course, any third-party module writers who want to use Libconf
should do so ..