home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0015.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  6.2 KB  |  129 lines
  1. Submitted-by: atkinson@cmf.nrl.navy.mil
  2.  
  3. >Why is POSIX ``standardizing'' printer interfaces? 
  4.  
  5. % Well, because you can't sell a system today that supports neither
  6. % SysV lp or BSD lpr; that seems to indicate the market has settled on a
  7. % couple of nearly universally reviled standards. You might ask the
  8. % Palladium gang from MIT-Athena about the degree of interest in their
  9. % stuff. You might check around at the number of implementations of it.
  10. % Lots and lots of implementation experience, just what you want to see.
  11.  
  12. Palladium is NOT widely implemented outside MIT.  
  13.  
  14.   As you yourself indicate, the demand is for EXISTING PRACTICE
  15. (either BSDish or SVIDish) and so of course POSIX will standardise
  16. NEITHER and instead standardise a technology which is not widely
  17. implemented in existing UNIX systems or most anywhere else outside of
  18. MIT.  
  19.  
  20.   They also are planning to standardise none of the usual existing
  21. printer user commands (lpadmin/lpstat/lpr/lpq) which is also baffling,
  22. especially since lp(1) _IS_ standardised by POSIX.2 and so different
  23. parts of POSIX will have incompatible user portability impairing
  24. characteristics.  Moreover, standardising the user interface doesn't
  25. restrict the underlying mechanism used to implement printers and
  26. queues so even the proprietary vendors haven't much room to gripe.
  27.  
  28.   Moreover, there is no apparent effort to standardise the printer
  29. networking protocol which is required for interoperability.  Note
  30. that a recent Internet RFC provides a public specification for the
  31. lpr protocol finally.
  32.  
  33.   The bottom line is that IF an area is to be standardised, existing
  34. practice is what should be in the standard.  
  35.  
  36.   TLI/XTI has always had protocol-independent networking as an
  37. objective, so the desire of POSIX to standardise this is more easily
  38. understood.  The key question is whether they will standardise
  39. existing practice (sockets and XTI/TLI) or whether they will go out
  40. and standardise some other new technology.  I hope to see sockets and
  41. TLI come out of the process, if anything at all.
  42.  
  43. > Where are the customer demands for these standards?
  44.  
  45. % Tell me - would you buy a system that didn't support Berkeley lpr and
  46. % sockets? If you're a SVR4 kinda guy, would you buy a system that
  47. % failed to support lp and TLI/XTI? *That* is customer demand.
  48.  
  49. See comments above.  Note that lpr is NOT being standardised; POSIX.2
  50. went with lp instead (which is fine since lp is also existing practice).
  51.  
  52. %  As for the solutions being poor, I happen to disagree with you
  53. % there; many of them are *different* from what you might think are good
  54. % solutions, but few of them are demonstrably poorer, and many of them
  55. % are demonstrably better against the set of criteria POSIX has to deal
  56. % with.
  57.  
  58. POSIX should not standardise anything that isn't widespread existing
  59. practice.  Palladium is an excellent of precisely what it should not
  60. standardise because it isn't existing practice in historical systems.
  61.  
  62. %  When's the last time you've been to a POSIX meeting, Dan? Perhaps
  63. % you might want to come down and watch the sausage being made; the
  64. % rules they play by address many of your concerns.
  65.  
  66.   Most mere mortals cannot afford to wander around the globe with air
  67. fare and hotel costs.  What us mere mortals can do (and at least some
  68. of us try to do) is to vote down the more outrageous inventions and
  69. object to some of the omissions when the draft hits balloting.  Even
  70. then it doesn't always work.
  71.  
  72.   For example, I really see a need for users to be able to give
  73. file(1) hints about new file types using the traditional, historical,
  74. well-understood option.  The committee has for 3 rounds insisted on
  75. misinterpreting my objection as demanding that file(1) _always_ use a
  76. "magic" file when my objection has said that the use of a "magic" file
  77. or any other mechanism to give file(1) hints on new file types.  The
  78. committee says that since I can't know all of the file types on all
  79. systems in the world that _NO_ extensibility mechanism is
  80. standardisable.  I think their argument merely confirms my assessment
  81. that some mechanism to allow users to give hints to file(1) is
  82. absolutely necessary.  Existing UNIX systems vendors all include
  83. file(1) and even the MKS folks include it for PCs (meaning that no
  84. effort would be required to implement the proposed option, so I
  85. speculate that it is a large vendor known for its proprietary OS that
  86. is behind this particular nonsense.
  87.  
  88.   Another example, I had several objections to POSIX.2 specs that were
  89. written in a way that was needlessly strict and meant that no trusted
  90. system could conform.  Some of these were accepted and the text
  91. rephrased, but others were rejected for reasons that remain unclear.
  92. In this case, it turns out that the POSIX.6 group is going to modify
  93. the semantics of the POSIX.2 draft in order to fix these, so the
  94. POSIX.2 draft will be modified (fixed) by the POSIX.6 ballot (which is
  95. currently out for review).
  96.  
  97.   The bottom line is that users are really coming out on the short end
  98. of the stick in this process because of the many places where POSIX is
  99. inventing or adopting new technology to standardise despite the
  100. existance of mechanisms in BSD, SVID, or shared by both.  In
  101. particular, people who do attend committee meetings keep telling me
  102. that vendors of proprietary systems repeatedly try to get the
  103. standards watered down so that their existing closed system can be
  104. marketed as POSIX-conforming or try to ensure that the existing
  105. practices are rejected for standardisation so that the open vendors
  106. are penalised.
  107.  
  108. Randall Atkinson
  109. atkinson@itd.nrl.navy.mil
  110.  
  111. DISCLAIMER:
  112. Views belong to the author, not necessarily his employer.
  113.  
  114. P.S.
  115.   Commercial announcements and such like create problems for many
  116. sites, particularly government sites which are under strict "no
  117. commercial use" rules.  If commercial announcements continue to be
  118. made to the comp.std.unix list, there is the possibility that USENET
  119. newsfeeds of the group will have to be dropped at a number of sites.
  120. This has happened at some agencies in the past and is a very real
  121. problem that is normally handled by the affected agencies by not
  122. carrying comp.newprod and any other group which has commercial
  123. traffic.  I'm not sure what NRL policy is on this, but I do know that
  124. it is true at a number of other sites both government and commercial.
  125.  
  126.  
  127. Volume-Number: Volume 26, Number 16
  128.  
  129.