Another message that did not get through the Mail->News link.
Aaron
From: "Jonathan L Cunningham" <jlc@sofluc.co.uk>
To: <pop-forum@cs.bham.ac.uk>
Subject: Re: forwarding message from Jonathan Cunningham (with comments)
Date: Wed, 22 Mar 2000 23:17:19 -0000
Steve Leach (Hi, Steve) says about environment variables:
>Actually, I understand that there is a good reason. Apparently it
>helps the Poplog devteam work with multiple versions. However,
I was resisting the urge to followup on this, but since I'm replying
to Aaron (below), I'll make the same point here. I would prefer to
say, not that "there is a good reason" but that "there was a good
reason".
Actually, with 20-20 hindsight (and inspired by the recent discussion
on this group), I think it is more accurate to say that the zillion
environment variables are one solution to a problem, and that poplog
is much better off with some solution than no solution.
But my point, and I think I'm just trying to make clear what people
(including Steve) were already saying, was that there are alternative
solutions, which might be more appropriate.
To summarise:
Houston, we have a problem.
Squintillions of environment variables can solve the problem.
Does it follow that therefore we need squintillions of environment
variables?
The correct answer is "no". If you answered "yes", can you see
your error?
Yes, of course you can. All you need to do is ask yourself, "How can
we solve this problem, in a poplog way, without using environment
variables?"
Internally, pop11 may need to distinguish skillions and whillions of
directories and search paths. The problem is simply to initialise some
internal data structure (or set of variables) with this information.
There is no reason why, when poplog starts up, it cannot read this from
a configuration file. The programming language "pop11" is quite
powerful enough for this purpose, and so the configuration file could
be written in pop11 (although I would probably design something
language-neutral).
This has already been stated by other people earlier in this discussion.
Of course, reading two dozen lines of pop11 code will slow down
startup by several milliseconds. Added up over future centuries of
poplog users, this could add up to minutes of human impatience. On
the other hand, you probably gain back more than it costs.
I don't think I'm saying anything that wasn't implicit in what both
Andrew and Steve have already said. I'm just trying to step back and
make it clearer.
Now I'll reply to Aaron's comments:
>1. Poplog, unlike linux default mechanisms, was always designed so that
>one can have more than one version installed simultaneously. So a new
Indeed. And environment variables were one way to achieve this.
>version could be installed on a system for testing by experts and brave
>people while the old version remains available for the rest. Later the
And a configuration file would let you do the same thing, without
knowing what an environment variable was.
>2. I don't know all the reasons why poplog has so many environment
>variables, but one reason they can be useful is if a common file server
Perhaps because it seemed like a good idea when there were only two
or three? And the number just grew and grew??
(snip)
>An alternative to having lots of environment variables in order to allow
>parts of the directory tree to be changed for various purposes, while
This is another mechanism which could, perhaps, be made to work.
I prefer the approach of a (pop11?) configuration file, with two dozen
assignments to (commented) variables, or (just perhaps), something
like an association list or mini-pop11 "database," you know,
something like:
[[auto ['/var/bin/poplog/lib/auto' '/users/aaron/auto']]
[xvedstuff ['/var/bin/poplog/lib/ved/xved']]
...
] -> variable_which_replaces_lots_of_environment_variables;
This is much too simplistic, so don't feel you need to point that out.
I'm merely reiterating the point(s) I made above: you don't need
environment variables. They are only a good solution when they are
a good solution.
The rest of Aaron's comments seem to me to be explaining, justifying
and defending the current mechanism, with suggestions for how it can be
improved.
In the interest of clarity, let me be explicit: it seems to me that
the drift of the discussion was not that the environment variable
mechanism needs to be improved, but that it could be replaced by a
purely poplog mechanism, and that this might have advantages.
To run poplog, even when there are multiple overlapping installations,
and many different users, you need two pieces of information:
(1) Which executable binary file to run (newpop, pop11 or whatever)
(2) Where your individual configuration information can be found.
If you were designing a solution to this from scratch, it is unlikely
you would invent the current mechanism. So if you wish to defend the
current mechanism, you have to be able to justify why a more elegant
solution cannot be used. "The current mechanism works" is not
sufficient justification to rule out discussion of alternatives.
Jonathan
|