Re: Binary configuration files as panacea to whatever ails Linux (was: Re: the problem with LINUX)

[Evgeny Stambulchik]

Oron Peled wrote:

And I still don't l;ike the current gconf: it requires an extra daemon

Worse! IIRC it's an extra daemon *per user*

So what? It's a reasonable solution for this kind of problem. In KDE, there is DCOPServer and a bunch of others running per user. ssh, when used properly (i.e. _easy_ access of several hosts with _strong_ authentication) requires the 'ssh-agent' daemon running per user. Why don't you rant on ssh implementation? Is it the word "daemon" that worries you? Yes, if it dies, bad things may happen. But same is true for e.g. xinit which is not a daemon. Why should it die in the first place if correctly implemented?

Also, replying to Evgeny:
  Having a standard and powerfull config mechanism is a GoodThing(tm)
  However, some "config" files in Unix/Linux are actually code
  (e.g: shell scripts, .emacs) which obviousely are more general
  than any config scheme you may come with.

The solution is to provide hooks for external interpreters. Just like server/client-side scripting is for HTML, I can imagine procedures executed either by the config daemon or the application itself.

  If the proposed config mechanism is very general, it would
  bloat simple applications and their authors (justfully) won't
  use it.

Very general doesn't mean bloated. The extensions are proveded via plugins and should be never exposed directly to the client. There is JavaScript available for HTML, but if I'm scared to learn it doesn't mean I can't use static HTML. The fact that there are a hundred Apache modules available (including those of alpha and beta quality) doesn't mean I should be afraid using Apache. I just don't load unnecessary/unreliable stuff.

  I do accept your observation, that in *many cases* there was no
  good reason to invent yet another poorly engineered config
  mechanism. I would suggest though, that a more realistic goal
  should be to *minimize* the number of different config types.
  For example:
	- A linear key=value pairs (e.g: INI files)
	- Hierarchic config (e.g: static XML)
	- Dynamic config (e.g: Registry/gconf)
	- Inherited config (e.g: environment variables)
	- .... where do I fit Xresources?
	- ... others

Of course, the limit of minimization of a natural number is 1 ;-). Seriously, it's not the number of configuration formats that worries me, but the fact that there is no well-defined API to deal with them at the basic OS level (i.e. no other dependencies than libc). This causes the present situtation when a given application implements a config API internally but don't export it and a GUI config tool author has to re-invent the wheel. But since re-inventing the wheel isn't an exiting task (especially as far as parsing a custom config format is concerned), he usually decides to either abandon the parsing at all (one-side mapping) resulting in any changes done either manually or by another tool silently lost or does implement it partially which works for (in the best cases) majority of the options but anything beyond that is either again lost or makes the tool crash/misbehave.

  So we may try to converge to some "best-of-breed" API in each
  category. Some categories may even need alternative selection
  due do special constraints:
	- On small footprint systems you trade flexibility for
	  footprint.
	- Some maintenance modes (e.g: single user) may force you
	  to manual config, so you cannot depend on running config
	  deamons (gconf, *SQL, etc.)
  So you may want both "full-blown" API and a "minimal-API" for
  the same category (similar to glibc and dietlibc).

Right. But notice that an application that compiles with dietlibc should compile/work nicely with the full-blown variant without even noticing.

Regards,

Evgeny


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]