I just *had* to comment.

[jc at trillian.mit.edu (John Chambers)]

miah wrote:
| This is the stupidest thing.. I don't know why anybody would waste
| their time with it.
|
| On Wed, Jun 02, 2004 at 12:46:03AM -0400, David Kramer wrote:
| > http://freshmeat.net/projects/registry/


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.

This hasn't been that big a problem, really. If it had been
a problem, it would have been fixed long ago. But there are
apps for which it is a problem. When writing a package that
consists  of  a  flock  of  cooperating processes, it could
often be useful if there were something like  environ  that
were global to all the processes. It can be done with a few
disk files, and a number of packages do it that  way.   But
they all do it differently, and they usually can't use each
other's files.

This registry is really just an attempt to produce  such  a
"global  environment vector" in a standard form, so that it
can be used consistently  by  different,  loosely-connected
packages.

Think of it as similar to the command-line  option  parsers
that  are available in several languages.  You don't really
*need* such a parser, as it's easy enough to write the code
to  parse  your  own parameters.  But there are a few minor
advantages to a library command-line parser. It saves a bit
of  time  in programming, and makes the command lines a bit
more consistent between different commands.

Similarly, a unix "registry" like this could save a bit  of
programmer  time  when a global list of name-value pairs is
needed.  And a published list of commonly-used items  (like
the usual PATH and USER environ values) could enable easier
inter-operation between different packages.

But I'd agree that most programs would never use it.   Just
like most programs parse their own command-line options.

I'm tempted to grab a copy and add it to  some  of  my  CGI
programs.  This seems like a case where it could be useful.
Maybe not, since all of my  CGI  programs  have  their  own
config  files  already.  But using this registry could make
the task easier, if they have actually done it right.