Re: [Libconf-dev] Generic services API

[dams]

"Brian J. Murrell" <address@hidden> said:

> 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.  :-)

ok :) sorry for the redondance then :)

>
>> 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.

That's right, it's a better system. And in case of multiple "printing API
shim", a choice has to be made.

>
> 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.

agreed.

>
>> 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?

well that's sound interesting, I didn't thought about dependency at an rpm
level. I thought we could do that within the object implementation in perl

>
>> 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

yes sorry, MTA :) I'm noob in many things, you know :)


We need to think about it. Let's try to build a precise dependency/requires
schema of an example. Could you try to do that with your rpm idea? I'll try to
do the same with perl objects.

PS : I have a huge quantity of work this week, I have a product to finalize, so
I'll be less responsive than normally. sorry for that


-- 
dams