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

[Evgeny Stambulchik]

Tzafrir Cohen wrote:

Think about embeded SQL. The backend could be a daemon (e.g. PostgreSQL),
but could also be a plain file (see SQLite). Basically, you just swap the
header files.

/me thinks: how can one binary work with all the different backends...

man dlopen. Or read existing code. Since we talked about SQL, the first thing that comes to my mind is UnixODBC (http://www.unixodbc.org/).

Ideally, there is a backend-neutral wrapper layer with many
plugins. Administrating a standalone desktop? Configure it to use local
files for the config data storage and don't worry about daemons. Just as
/etc/hosts vs. named. A more complicated schemes including local caching
etc are possible, too.

Anyway, one thing you should look at is libc's nss (name service switch),
which allows selection in run-time of the name-resolution method for each
of the "services". But this is a read-only configuration.

Hmm, and in which way is it related to a generic configuration API? I used the hosts/named example just to show how the same functionality can be achieved both with and without a daemon - with applications not having a slightest idea whether the NS answer comes from a remote server or /etc/hosts.

And anyway, I remind you that there is already a remote access protocol on
linux that is quite powerful, and works very well. It also fits into the
unix framework: rsh/ssh

Fantastic. Ever wondered why people invented HTTP? Of course, these were
Windows freaks who didn't know how to use telnet. The "unix framework"
would be to ssh to the web server and run the browser there. Right?

Hey: I specifically excluded telnet!

What's the principal difference here, for the heaven's sake?

Anyway, http is a simplified ftp, not a simplified rsh.

Exactly. So you answered yourself. When there is a remote data (HTML files in the case of WWW) there are two ways for a user to access the data: 1) login to the remote computer and run an application (web browser) there and somehow display the application's interface back or 2) retrieve the data to the local system and run the app locally (and send the modified data back, if required, using the same protocol that was used for fetching it). The second approach is called "the client-server model". Shall I go in depth proving that 2) is superior?

I actually access my imap account via ssh to the mail server ('ssh
mailserver /path/to/imapd') ...

No. What you're doing is tunneling the IMAP protocol via the ssh tty session. Why you're doing so is quite beyond my understanding, though (a firewall blocking the IMAP port? - but why not usual port forwarding that ssh is so good at?). At the other end of the ssh pipe an IMAP-capable mail reader is listening anyway.

If rsh/ssh is the ultimate answer to the
remote management, then vi is the ultimate configuration GUI. Not?

You seem to confuse "usage" and administration" in the above examples.

No, it's you fail to realize that "administration" is a form of "usage". For a web browser application the data is HTML files. For a management console, the data is config info.

It is a powerful remote administration tool that you should not break.

??

There is one thing you should keep in mind: GUI can't be automated.

Why did you jump at GUI? Whether I'm using Mozilla to browse the Net or downloading a Mandrake ISO with wget the HTTP protocol comes handy. And both Mozilla and wget could potentially use the same HTTP access API if such a thing existed on all flavours of OS the two applications are running. Same about IMAP: KMail (GUI) and fetchmail (GUI-less) both use it instead of logging to the remote server via ssh. Same about config.

An API, as nice as it is, still takes some effort to automate.

Come on. The point is _unification_. If a device has ten screws, nobody would deny it's more complex to deal with than a single one. But if each of them is different in size/form... Yes, that's the current state of affairs in the Unix world of configuration. A nice car with hundreds of screws of different types. You have to learn how to use a few dozens of different screwdrivers. For a few large polished screws you can buy an electric screwdriver; however, 1) the electric tool, albeit fast, is very rough and 2) once you started using the advanced tool, an attempt to tighten one of the polished screws with a usual screwdriver risks the car stop working. Imagined?

If you want something done via cron: you need a shell command.

Sorry, I lost you here completely. What did you try to say?

Another thing to keep in mind: current package management tools are built
around files. A file cannot be part of two packages. Config files fit very
nicely into this scheme: there is a clear definition who is responsible
for each config file.

The "clear" definition appears very dirty at a closer look. Ever tried changing hostname of a multi-protocol server? The hostname pops up in a dozen of different config files. Which package is responsible for hostname? Plus, it should be changed on all clients accessing the server and possibly in the firewall configuration.

If more than one package should change a certain
config file, then the package

Which of the two (or more)?

providing this file must provide the
(command-line) API to edit this file safely.

There would be no need for the primitive tools like vipw if the config API took care of the locking/concurrent access issues. And it is much easier and more reliable in C than dumb locking that vipw uses.

This modularity is another thing that has to be maintained. One thing that
has to be done in any such configuration scheme is to define "domains"
whose are in the responsibility of certain packages.

Is it impossible?

Another point: you mentioned cups as a good example of a package with a
clear configuration API

No, I mentioned CUPS as a good example of the printing subsystem with a clear printing API. Other printing systems (BSD lpr,...) don't provide API at all. Results: enabling printing for a third-party application using CUPS is a snap from the programming point of view.

But if you design a generic config API, you simply don't have the right
"actions" or "verbs" in advance:

I don't need them. An XML editor can parse and load _any_ XML dialect, be it XHTML or SVG. And if you know what're you doing you can make any changes you want, including those breaking the specific format (but not XML as such). But if, in addition, you provide a respective DTD, the editor will become really smart - like colorizing the text, putting icons, providing help tips etc. So, each application can provide its own config schema. I suggest you read the GConf docs (http://www.gnome.org/projects/gconf/).

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]