Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix
From: randall@uvaarpa.virginia.edu (Randall Atkinson)
Newsgroups: comp.std.unix
Subject: Reactions to the 12/1989 Standard Summaries
Message-ID: <459@longway.TIC.COM>
Date: 2 Dec 89 23:17:54 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: randall@uvaarpa.virginia.edu (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Lines: 65
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: randall@uvaarpa.virginia.edu (Randall Atkinson)

Before I get into the technical reactions, I'd like to make public
complaints about the way that the IEEE is handling access to draft
materials from the 1003 working groups.  I have contacted the IEEE
by phone and postal mail asking how to get mailings of the drafts
so that I can comment on the proposals on a timely basis.  The IEEE
has verbally indicated that they "would get back to me" with details
on how to do this but have not.  My employer isn't going to send me
off to actually join the committees and I'm not independantly wealthy
so it just isn't possible for me to take a more direct role.

I am appreciative of the efforts of the USENIX Watchdog Group, but
wish that those of us on the sidelines could get more response from
the IEEE on how to get the draft materials for review before they become
standards.

  I am concerned that both 1201 and 1003.8 are going to end up giving
a rubber-stamp to existing commercial products (however good they might 
be) rather than giving us the portability and functional capabilities
that might be needed.

  The discussion of the problems when multiple processes are accessing
the same file through a TFA mechanism is well taken.  As a developer of
software I want to have a clearly defined behavior.  If there are 
"options" it is much more difficult (if not impossible) to write
portable software.  If there is inadequate definition of the behavior
or definition in any way inconsistent with a strict interpretation of
1003.1, it again seriously diminishes the usefulness of the resulting
standard.  NFS is a fine product; I would hope that the committee 
will look beyond it however to something that gives more guarantees
about the behaviour of writes and reads.  If 1003.8 is mostly a rubber
stamp of NFS, it will not do most of us much good.

  The API of 1201.1 should NOT be based primarily upon OpenLook, Motif,
NeXT Step, and the Apple Macintosh.  Instead, what is needed is a generic
interface that will provide a complete set of routines that aren't bound
to any specific existing GUI.  I believe that all GUIs have much room
for improvement (especially in the International arena where icons for
the US often make little sense) and I don't want reasonable improvements
to be locked out by a poorly designed standard.

  I don't have enough information to comment specifically on what
1201.2 is trying to accomplish, but again I do not want to see the
IEEE rubber stamp Motif, OpenLook, or any other "style."  It is 
premature for the IEEE to standardise the style at this point.

  I feel (and have felt since the original trial-use standard) that
the 1003.1 standards group erred in having quite so many options
to the standard.  It appears that the NIST agrees since the FIPS
interpretation of 1003.1 eliminated the worst of these uncertainties.
Other standards groups in the 1003 and 1201 area should pay particular
attention to this and avoid creating standards that have optional
behaviour.  If published standards have options, the marketplace will
eventually narrow them down to a de facto single standard option and
this narrowing down is precisely the point of having standards groups.

  Regards,

   Randall Atkinson
   randall@Virginia.EDU

   Opinions are the author's.

Volume-Number: Volume 17, Number 86