I just *had* to comment.

[John Chambers]

David Kramer writes:
| On Wednesday 02 June 2004 10:02 am, John Chambers wrote:
| >
| > Well, I can see a simple way of describing the problem that
| > it would help solve. A common question from unix newbies is
| > "How  does  my  program  make  a  global  change   to   the
| > `environment'?"  The  traditional answer, of course, is "It
| > can't; the environment vector isn't global."  Unix  doesn't
| > keep  any  global  data for processes; that's what the file
| > system is for.
|
| A registry does not fix the problem you outline.  If the program is designed
| to get information from "the environment" (which I take you mean environment
| variables), then having a registry in place will not change anything.  If
| you're now talking about changing this application to get this information
| from the registry, then how is that any easier than changing the application
| to get this information from a config file?  There's no advantage.

Depending on how it's implemented, it could change a lot  of  things.
For  example,  in  perl  I can use $ENV{PATH} .= '/foo/bar'; to add a
directory to the search path, but only the current  process  and  its
children will see this.  If the program writes this to a config file,
other processes need to keep timestamps and  call  stat($cfgfile)  to
detect changes.  A registry could allow me to call
   $path = regget('PATH');
to get the search path.  Then a call of
   regset('PATH',"/foo/bar:$path");
would change the search path in the registry, and any of the flock of
processes could call regget('PATH') to get the current  search  path.
This  does  nothing that can't be done with files, but it reduces the
coding to a pair of library routines.  No mystery here; that's why we
have libraries of routines.

Going further, we could make regget() and regset() communicate with a
server  via  TCP  or  UDP,  and then the search path could be changed
instantly for processes on a set of machines. This is difficult to do
at  all  with  files.   It  is doable with NFS or SMB or AFS or other
distributed file systems, of course, but  doing  the  synchronization
right  is  tricky.   Doing  it in a server is a simply way to get the
synchronization in a way that is invisible to the processes.

Of course, not many people want to do something like this.  I'd guess
that  this  registry  process will find a few enthusiastic users, but
most programmers would say "Who needs it?" Unlike Windows, unix/linux
users  will  find  it  a  voluntary registry, and most will choose to
ignore it.

| You haven't yet stated how having a binary registry is easier that a text
| config file that can be copied, diffed, version controlled, merged, edited,
| and verified by a human with standard POSIX tools.

I'd be very dubious of a binary registry.  But if it works through  a
server, I see no reason that the server's data shouldn't be backed up
on disk in plain-text files.  Sounds like a good idea to me.  And  if
the  server checks those files' timestamps frequently, you could edit
them, write your changes, and watch the registry server pass on  your
changes to all the running programs that use the registry.

Back in the 70's, most of the commercial software used binary  config
files,  and  each package had its own idiosyncratic tool for managing
its config file.  It took a lot of training (and a lot of manuals) to
learn how to configure all the packages on a machine. One of the real
advances in unix was that almost everything had a  plain-text  config
file.   This meant that you only had to learn one tool (an editor) to
manage all config files.  This was a major productivity advance  over
commercial systems.  We should keep this advantage.

There's no reason a registry's files need to be binary.  This  is  as
bad an idea now as it was back in the 70's.  Plain text still has all
the advantages that it ever had.