Configuration API

Sean Middleditch elanthis at awesomeplay.com
Wed Apr 28 00:57:50 EEST 2004


On Tue, 2004-04-27 at 17:45 -0300, Avi Alkalay wrote:
> Of course.
> 
> What I mean was: Should this API/library be designed to be used also by
> non-desktop software (Apache, Samba, mount, pure glibc, modprobe, etc that
> WANTS to use it), or only for desktop apps?

Which I addressed for the case of real server apps...

There's no reason to touch mount, modprobe, libc, or other
non-user-oriented utilities.  There's no realistic use-case for it other
than "hey it's cool let's change because that somehow means it's
better!"  Modprobe configuration should _never_ be human edited in an
ideal machine, it should be automatic.  Same with mount configuration.
We can thank udev/HAL/D-BUS for that.  :)

> 
> If the first is true, the design must think about dependencies and
> simplification.

If you're trying to suggest that those are somehow mandatory for server
apps, then no.  Dependencies are an implementation detail and have 0
impact on an API.  If we're talking about the dependencies of a backend,
then sure.  That's the whole point of having pluggable backends; you can
pick one best suited to your needs, and the administrator (the person
who knows the system needs the best) can make that choice freely.

Simplification (which I'm assuming you mean reduced functionality due to
some false perception of "bloat", not cleanliness/style of the code) of
the API is also silly; if the API can't do what certain apps need, then
those apps are incapable of using the API.  On the other hand, apps that
don't need all the features exposed through the API are not required to
use all of them.

If you have some specific examples of what a server app does and does
not need in the API, please say so.  General statements like "server
apps need less dependencies" are rather useless in terms of designing a
good general purpose API, just like saying that "bachelors don't need
SUVs" is useless in determining the proper dimensions for a general
purpose garage...

> 
> Regards,
> Avi
> 
> 
> ----- Original Message ----- 
> From: "Sean Middleditch" <elanthis at awesomeplay.com>
> To: <xdg at freedesktop.org>
> Sent: Tuesday, April 27, 2004 3:49 PM
> Subject: Re: Configuration API
> 
> 
> > On Tue, 2004-04-27 at 14:10, Avi Alkalay wrote:
> > > I agree something must be defined.
> > >
> > > Do you guys think it is important for this API to be desktop-apps-only
> wide,
> > > or also systemwide?
> > > Like, should XFree, Apache configuration be accessible through this API
> too?
> >
> > If they want to be.  It's up to them.  You can't shove configuration
> > systems/APIs down peoples' throats.  The X11 server (XFree86 or
> > otherwise) is something that should be configurable on the fly IMO given
> > that it *is* a desktop component, though.  ;-)
> >
> > Do server projects impose any additional needs on a configuration API?
> >
> > An administrator running a server farm might *love* to have Apache for
> > example share its settings with other servers on the network and all
> > support change notification to provide for simplified central
> > administration.  (Admin opens tool on his desktop, changes a setting
> > that gets distributed across the network using a cluster-oriented
> > backend, apache processes pick up the change and adjust accordingly.)
> >
> > They would perhaps require atomicity for change sets (you don't want to
> > open temporary an access/security hole because some changes that should
> > have been made all at once are picked up and immediately handled one by
> > one).
> >
> > >
> > > Regards,
> > > Avi
> >
> > -- 
> > Sean Middleditch <elanthis at awesomeplay.com>
> > AwesomePlay Productions, Inc.
> >
> >
> > _______________________________________________
> > xdg mailing list
> > xdg at freedesktop.org
> > http://freedesktop.org/mailman/listinfo/xdg
> >
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
> 





More information about the xdg mailing list