On Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
I just posted an update to the environment draft; it should be in the
repository soon.
Seems short and sweet.
In addition to adding a note about using "name."
prefixes to group related standard items,
That note is actually the only thing that gave me pause. When I read:
> Extensions designed for interoperable use SHOULD be defined in
> standards track or experimental RFCs. Groups of standardized items
> MAY choose to use a common name prefix of the form "name.".
it took me a few passes to realize that this was not recommending the
literal prefix string "name." (perhaps relating to the "name"
environment item) but recommending grouping related items by some prefix
"xxx." where "xxx" is replaced by some mnemonic for the category by
which they are related. I dunno if that's even worth mentioning, but
there it is, mentioned.
Fair enough. When the document is next updated I will add ", where "name" is a
string that identifies the group of related items." to the end of the last
sentence.
A couple of other musings, again perhaps not worth mentioning, but
while I'm here:
There is a "host" item listed, which is the FQDN of the local host.
It seems to me that one might want to know the host-only part of that
string. One could obtain it in a round-about way by using the "domain"
environment item and the "host" item; but is it worth adding "host-only" ?
Frankly, I think the use of shortform names is a bad thing that should be
discouraged whenever possible. (IT uses them extensively here at Sun and they
cause no end of problems.) I'm therefore very reluctant to add such an item.
I also think that the draft could benefit by providing for some behavior
in the presence of the "variables" extension, e.g. by defining a
namespace such as "env." and stating what value is returned if the item
is undefined in the implementation. I realize that one could obtain the
values by using :matches, wildcarding, and variable assignments;
having namespace support would be more straightforward.
First of all, the specification says that any test against an unknown
item must fail unconditionally. This provides a simple way to check and
see if a given item is available:
if environment :matches "item" {...}
This test only succeeds if "item" is defined. Since this doesn't appear
to be obvious I think I'll add a note about it to the text.
I did consider using namespaces as a means of returning multiple/structured
values from environment tests, but I eventually decided it wasn't worth it.
Ned