Configuration API

[Avi Alkalay]

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

I don't agree, but I don't want to start a religious discussion again.
Just to say: this 20 years old configuration files must evolve some day. Not 
because it is cool, but because it is programatically easier for other 
software to integrate with those old ones. END OF THIS SUBJECT, please.


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

Too much choice is not allways good.



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

I undestand, but I think in the other way: Lets try to do something really 
generic and simple, for any purpose, and then do specializations on top of 
it.
Making it too specialized or full featured sounds to me like implementing HTTP 
to do TCP/IP stuff (that old discussion...). I'm saying that inspired by a 
Doc Searls article, specially in this parts: http://worldofends.com/#BM3 
http://worldofends.com/#BM4
All of it is a great reading also: http://worldofends.com/#BM1

I think that defining several data types is another too-specialized approach. 
I guess even KDE and Gnome themselves don't agree the way they store a font 
name+size+etc, or color, time, recen files, etc. Even the simplest integer or 
float types may be subject to limits, etc. Not in the way they are stored in 
the configuration file, but the C type the API returns (float? double? long 
int? long long int? and if somebody needs more?). And we can't cover all data 
types in the world, or future ones. So I think people will start to allways 
use Strings (for int, font, float, color, etc), just because they are 
supergeneric and easy.


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

I think they don't care about dependencies, unless the dependency is not 
available. So adoption or not will be based on "is that dependency available 
in that context?". I'm thinking about people that writes software that must 
be portable to Windows, Mac, UNIX, etc, like Apache or Java based sw.

And regular server software is the easy part. Super basic system software are 
more challenging.
And they specifically don't need nothing more than what they already have (a 
plain text file). But, other software (that wants to integrate itself with 
them, automatically) may want to clearly see how they are configured and 
possibly change it. So this is desirable not for 'mount' or 'modprobe', but 
for an integrated system as a whole.

Regards,
Avi


-- 
Avi Alkalay
SW & IT Architect :: Linux, Open Standards
 
Linux Impact Team :: ibm.com/linux
* avi at unix.sh
* 55-11-2132-2327
* 55-11-9659-9059 (mobile)