I just *had* to comment.

[david at thekramers.net (David Kramer)]

On Wednesday 02 June 2004 10:02 am, John Chambers wrote:
> 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.

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.


> 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.

I beg to differ.  Information that is pertinent to many appications is usually 
stored in config files right now, and it works just fine.  All the 
information about the network, mounted filesystems, users and groups, 
system-wide shell initialization, scheduled tasks, processes, and devices are 
all available to any application that needs that information.

If you want to propose a common config file format, like the ond-school 
Windows INI format (with [SECTION] tags, or XML) I could get behind that.

> 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.

If all you are asking for is a place to define environment variables that will 
be set whenever any user instantiates a shell, there are already files for 
that in /etc.  For instance, one of my projects for Polaroid was to help 
Release Engineering set up a development and build environment.  Part of my 
implementation was setting up a /etc/bash.bashrc.local that would define the 
particulars of each machine in one central place, so all my other scripts 
would know where java, ant, gcc, junit, JBuilder, the project workspacem and 
the install directory were, as well as the release of Linux, whether the 
system had an emulator board to simulate the hardware of the final product..


> 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.

... And that's why they already exist in C, C++, Perl, PHP... Look around and 
you will find libraries that know how to read various config file formats in 
most common languages.

> 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.

How is it easier to use a binary config file that you need (and must trust) 
special programs to modify, over text files that can be manipulated using 
standard POSIX tools like sed?

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

Not really.  Most programs use whatever equivalent for getopt exists in their 
language.  C has getopt.  Java and Python has methods in the System class.  
Perl has the Getopt module.  And so on.  This is a problem that's aready 
solved.

> 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.

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.


--
DDDD   David Kramer                           http://thekramers.net
DK KD  
DKK D  "Some men are born mediocre, some men achieve mediocrity,
DK KD  and some men have mediocrity thrust upon them."
DDDD         -Joseph Heller (1923-1999) "The Great Executive Dream"