[ 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
framework.
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
parser.
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.