[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libconf-dev] Generic services API
From: |
dams |
Subject: |
Re: [Libconf-dev] Generic services API |
Date: |
Mon, 16 Jun 2003 12:36:47 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
"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