Re: [Libconf-dev] Generic services API

[Brian J. Murrell]

On Sun, 2003-06-15 at 12:19, address@hidden wrote:
> 
> This is a good idea, it's slightly the same goal as the global libconf 
> project.
> If you look at the global diagram here :
> 
> http://qa.mandrakesoft.com/twiki/bin/view/Main/LibconfProject

Yes, I have seen everything there was in the Wiki.  It was what lead me
to here in fact.  :-)

> You'll see that it's what we want to do.
> But it needs some explainations. On the diagramm you'll find :
> 
> libconf : this is the very low level parser, that parses a single config file.
> glueconf : this is the middle layer, it provides a very convenient structure 
> representing a
> single config file
> systemconf : this is the upper layer, it provides a very convenient structure
> representing a configuration theme, like "network", "printing system", or "X
> configuration", that rely on multiple glueconf structure, ie multiple 
> different
> config files.

Right.  Maybe what I am describing is what is in the "Libconf APIs".  I
dunno.  It was difficult to tell what that layer describes.

> In addition, I'd like to add high level function into the system conf modules,
> like addPrinter('cups', 'usb', 'local',...), or addADSLConnection('pppoe',
> 'ethernet', 'eth1')...
> 
> These high level functions would ease the construction of wizards.

Yes, but they should be more generic (my specific nit is the passing of
the "cups" argument).  For instance, addPrinter() should be provided by
the CUPS "printing API shim".  The layer calling addPrinter() should not
care that it's CUPS, or LPRng or whatever other spooler we wanted to
support.

The layer I am describing should abstract out the details of a specific
spooler into generic configuration functions that any configuration tool
should be able to call consistently and any print spooler should be able
to provide.

> For now a systemconf module is static, we should introduce some 
> provide/require
> system.

Hmmm.  Indeed.  This provide/require could (and probably should) be done
at the RPM level.  Each "service" that you want to configure could be an
RPM that installs into the Libconf framework.  So there would be a (set
of) base package(s) providing the Libconf framework and then there would
be service modules, such as libconf-e-mail, libconf-internet,
libconf-aaa, etc.

Each libconf-<service> module would then have a list of requires, so
libconf-e-mail would require "mta", "mail-store", "aaa", and components
such as Postfix and Exim and Sendmail would all provide "mta", and
cyrus-imap and courier would provide "mail-store", etc.

Does this sound half baked?

> Because a systemconf module is composed of glueconf modules, I think
> each glueconf module should tells what it provides (postfix glueconf would
> provide AAA).

postfix glueconf provides AAA?  Don't you mean provides MTA?  PAM would
be an example of AAA.

b.

-- 
Brian J. Murrell <address@hidden>

signature.asc
Description: This is a digitally signed message part