On Sun, 12 Jan 2003, Evgeny Stambulchik wrote:
> Tzafrir Cohen wrote:
>
> >>Hence, this approach is wrong. Webmin, LinuxConf, YAST, DrakeConf, you name it.
> >>Huge duplication of efforts and _none_ of the above working properly. You need
> >>an API ("abstraction") that will both generate AND parse the configuration.
> >>Moreover, the Apache itself MUST use this very API. And all other servers and
> >>applications. Throw in replication and remote access protocol and that will be
> >>the sysadmin's paradise... And no, I don't mind it sounds like Active Directory.
> >
> >
> > 1. This means rewriting apache.
>
> No. It means either a) {if the Apache style of config is considered the
> best} extracting the relevant part of Apache into an independent library
> or b) designing the config API from scratch and throwing away the old
> cruft (which isn't a major part of the Apache codebase anyway).
>
> > Recall that apache is used not only on
> > linux, but on hosts of other platforms. Some linux developers tend to be
> > linux-centric, and ignore the fact that the same software needs to run on
> > other platforms.
>
> I wholeheartedly agree that for such a base API to catch on, it must be
> highly portable.
>
> > 2. gnome (partially in 1.4, more so in 2.0) is a test to such a
> > technology.
>
> As I wrote earlier, I in general like the GConf ideas, but it's bound to
> Gnome (well, it's supposed to be used kinda standalone, but since it
> further depends on about dozen of libraries which you never find on
> non-Gnomified systems... and of course, linking a daemon like crond to ten
> libraries just to parse its config is definitely an overkill).
>
> > Am I the only one who thinks a configuration daemon is bad?
>
> Why is it bad (if correctly implemented)? And why the daemon is a must?
> 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...
> 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.
>
> > 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!
Anyway, http is a simplified ftp, not a simplified rsh.
> And
> IMAP is completely obsolete in the unix framework, too: ssh to the mail
> server and open inbox in vi.
I actually access my imap account via ssh to the mail server ('ssh
mailserver /path/to/imapd') ...
> 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.
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. An
API, as nice as it is, still takes some effort to automate. If you want
something done via cron: you need a shell command.
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. If more than one package should change a certain
config file, then the package providing this file must provide the
(command-line) API to edit this file safely.
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.
Another point: you mentioned cups as a good example of a package with a
clear configuration API (though it seems to require a certain daemon
listening on a certain port, IIRC).
There is one difference between a general configuration scheme and a
specific configuration scheme: the designers of cups's config API were
aaware of the meaning of every action: they knew what "print" will do,
etc.
But if you design a generic config API, you simply don't have the right
"actions" or "verbs" in advance: It seems that what you want is an API
that will expose all the actions that can be performed on the config of a
service, rather than a low-level API to edit the config of the service.
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir
=================================================================
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]
