libconf-dev
[Top][All Lists]
Advanced

[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: Fri, 27 Jun 2003 01:15:56 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

hello it's me again! sorry for the delay, have had a hard week, very busy.

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


[...]

>
> I'm not terribly familiar with the object-ness of perl to be honest.  I
> have no idea how dependencies work in Perl objects, but regardless of
> that, those dependencies would need to percolate up to RPM anyway,
> unless you see the Libconf for all systems being bundled up into one
> RPM.

I have had little time to think about it, but here are some thoughts :

in the perl object implementation, as far as I know, if you call one method
that is provided by multiple class of one object, only one is elected and
its method called.

So we cannot use the perl object directly (like, make one "printer" object that
inherits of "cups", "lpd", "pdq"...).

I think I'll implement a dependency structure in the libconf perl module,
probably a hash, that describes the dependencies.inheritances of the systemconf
objects. Yes, I forgot to say, that only systemconf objects will be able to
depend on each other.

something like : 

{
        mail => {
             AAA => [ qw(foo bar) ],
             MTA => [ qw(postfix, sendmail) ],
        },
        printing => {
                 server => [ qw(cups lpd pdq) ],
                 ...
        }
}

Each systemconf provides a tie-ed hash linked to various glueconf modules, but
also the "high-level" methods (btw we should find a better name, don't you
think?).

With the given structure above, there should be these systemconf modules:

mail, AAA, MTA, printing, server, that all implement some default "high-level
method", for example configure(); Each configure function could call the
configure functions of the dependend modules.

The structure could also be a directory. That would make things easier, when
installing a new MTA, which would add itself in the dependency tree.

Or maybe perl modules that are required/used automagically... 


The other points to be done are:
1/ let libconf provide its set of default libconf/glueconf/systemconf templates,
but allow packages to install up-to-date templates. Libconf would then take in
priority the up-to-date templates, or the default if none is found. I'll find
out how to do that with perl modules, so that when I say 'use
postfix_template qw(1.12)', it uses the tempaltes in
/a/path/to/libconf/postfix/1.12/template.pm if it exists, an otherwise
default to /a/path/to/libconf/postfix/default/1.12/template.pm, and otherwise
default /a/path/to/libconf/postfix/default/all_version/template.pm
Something like that...

2/ implement the validation (now what an IP address is, and make the gui
generator aware of that (a of awsare of the comments too)

3/ code confSystem (http://qa.mandrakesoft.com/twiki/bin/view/Main/ConfSystem)
or other stuff.


-- 
dams




reply via email to

[Prev in Thread] Current Thread [Next in Thread]