Re: [Libconf-dev] Generic services API

[Brian J. Murrell]

On Mon, 2003-06-16 at 06:36, address@hidden wrote:
> "Brian J. Murrell" <address@hidden> said:
> > 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.

Actually I don't see it that way.  If the API calls are handled more
like event/callback registration where the both the CUPS spooler and
LPRng spooler register their API hooks, both will get called by Libconf
and both spoolers will get configured similarly.

Generally there is no problem configuring two spoolers, completely
identical so long as only one is running at a time.  Some might even see
this as an advantage as they can try each and switch back and forth if
they liked.

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

But I want to see it abstracted to the point that the configuration
tools don't know or care what packages are being used to provide a
service.

> 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

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.

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

NP at all.  I just wanted to amke sure we were all talking about the
same thing.

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

Since you know the framework and have a vision of what you'd like to
see, I'll let you go first, then at least I will know how to express my
ideas in a format that will be the same as yours.

> 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

NP at all.

b.

-- 
Brian J. Murrell <address@hidden>

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