home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0077.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  3.3 KB
  1. From: randall@uvaarpa.virginia.edu (Randall Atkinson)
  2.  
  3. Before I get into the technical reactions, I'd like to make public
  4. complaints about the way that the IEEE is handling access to draft
  5. materials from the 1003 working groups.  I have contacted the IEEE
  6. by phone and postal mail asking how to get mailings of the drafts
  7. so that I can comment on the proposals on a timely basis.  The IEEE
  8. has verbally indicated that they "would get back to me" with details
  9. on how to do this but have not.  My employer isn't going to send me
  10. off to actually join the committees and I'm not independantly wealthy
  11. so it just isn't possible for me to take a more direct role.
  12.  
  13. I am appreciative of the efforts of the USENIX Watchdog Group, but
  14. wish that those of us on the sidelines could get more response from
  15. the IEEE on how to get the draft materials for review before they become
  16. standards.
  17.  
  18.   I am concerned that both 1201 and 1003.8 are going to end up giving
  19. a rubber-stamp to existing commercial products (however good they might 
  20. be) rather than giving us the portability and functional capabilities
  21. that might be needed.
  22.  
  23.   The discussion of the problems when multiple processes are accessing
  24. the same file through a TFA mechanism is well taken.  As a developer of
  25. software I want to have a clearly defined behavior.  If there are 
  26. "options" it is much more difficult (if not impossible) to write
  27. portable software.  If there is inadequate definition of the behavior
  28. or definition in any way inconsistent with a strict interpretation of
  29. 1003.1, it again seriously diminishes the usefulness of the resulting
  30. standard.  NFS is a fine product; I would hope that the committee 
  31. will look beyond it however to something that gives more guarantees
  32. about the behaviour of writes and reads.  If 1003.8 is mostly a rubber
  33. stamp of NFS, it will not do most of us much good.
  34.  
  35.   The API of 1201.1 should NOT be based primarily upon OpenLook, Motif,
  36. NeXT Step, and the Apple Macintosh.  Instead, what is needed is a generic
  37. interface that will provide a complete set of routines that aren't bound
  38. to any specific existing GUI.  I believe that all GUIs have much room
  39. for improvement (especially in the International arena where icons for
  40. the US often make little sense) and I don't want reasonable improvements
  41. to be locked out by a poorly designed standard.
  42.  
  43.   I don't have enough information to comment specifically on what
  44. 1201.2 is trying to accomplish, but again I do not want to see the
  45. IEEE rubber stamp Motif, OpenLook, or any other "style."  It is 
  46. premature for the IEEE to standardise the style at this point.
  47.  
  48.   I feel (and have felt since the original trial-use standard) that
  49. the 1003.1 standards group erred in having quite so many options
  50. to the standard.  It appears that the NIST agrees since the FIPS
  51. interpretation of 1003.1 eliminated the worst of these uncertainties.
  52. Other standards groups in the 1003 and 1201 area should pay particular
  53. attention to this and avoid creating standards that have optional
  54. behaviour.  If published standards have options, the marketplace will
  55. eventually narrow them down to a de facto single standard option and
  56. this narrowing down is precisely the point of having standards groups.
  57.  
  58.   Regards,
  59.  
  60.    Randall Atkinson
  61.    randall@Virginia.EDU
  62.  
  63.    Opinions are the author's.
  64.  
  65. Volume-Number: Volume 17, Number 86
  66.  
  67.  
  68.