I think this is a key feature; I really like interfaces to mildly
structured data in the form of name:value pairs, because it does make
it easier to identify what you want without having to impose additional
structure on the information itself, structure that has to be known
by all participants. As Keith implies, having data explicitly tagged
makes the interface less fragile; how many people have been inconvenienced
because their version of ps or top of fuser breaks unexpectedly every now
and then? Related versions of this problem have already been solved (albeit
in a somewhat ugly fashion) by SNMP MIBs. Note that I'm less concerned
about making the /proc output more human-readable than with making the
interface between programs less fragile, but it would be nice if both
could be done. Most people likely to be looking at the contents of
proc files should have a reasonable idea what they're looking for anyway,
but it seems obvious to me that a list of tagged values is more
understandable than a row of anonymous numbers (although there are
many FORTRAN programmers who seem to believe otherwise...).
>I would like to see a clean break to tagged text for *all* proc files. That
>way we only get caught once when the change is made, thereafter user mode
>utilities will simply ignore /proc fields they do not recognise, making for a
>much cleaner upgrade path.
Of course, this is a clear benefit, but there is also a danger that
a semantic change will break the older utilities in a much more profound
way. It may also be worth considering the addition of a version number to
the proc data, which can provide hints to the programs that read the data
about whether it's legitimate for them to use it. For example,
the client programs must share the same major number, but can be out-of-date
on the minor numbers.
-- Frank Wales [frank@limitless.co.uk] "Please state the nature of the Internet emergency." --the emergency holographic systems administrator