home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0024.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  7.3 KB  |  166 lines
  1. Submitted-by: pc@hillside.co.uk (Peter Collinson)
  2.  
  3. USENIX Standards Watchdog Committee
  4. Stephen R. Walli <stephe@usenix.org>, Report Editor
  5. POSIX.7: System Administration
  6.  
  7.  
  8. Bob Robillard <duke@cc.bellcore.com> reports on the July 13-17, 1992
  9. meeting in Chicago, IL :
  10.  
  11. Overview of POSIX.7
  12.  
  13. Since this is the first snitch report on POSIX.7 in quite some time,
  14. I'll start with some background.  (If you already know what POSIX.7's
  15. been up to for the past year or so, you can skip ahead some). POSIX.7
  16. is one of the three POSIX ``Base Standards'' (POSIX.1 and POSIX.2 are
  17. the other two).  It covers the kinds of commands typically found in
  18. section (8) of the man pages - things like fsck and init.
  19.  
  20. Early on, POSIX.7 decided to address distributed system
  21. administration, rather than just single machine administration, in the
  22. belief that networked computing is the way things are going.  This has
  23. caused a great deal of trouble since distributed system administration
  24. is relatively new and perhaps less ready to be standardized than
  25. stand-alone administration. The hope, however, is that the final
  26. standard will be more useful.
  27.  
  28. In the last year, POSIX.7 broke its work into several pieces.  Each
  29. area of system administration is getting its own document.  The
  30. current POSIX.7 ``sub-groups'' are:
  31.  
  32.    - POSIX.7.1 - Printing Administration,
  33.  
  34.    - POSIX.7.2 - Software Installation and Management, and
  35.  
  36.    - POSIX.7.3 - User and Group Administration.
  37.  
  38. POSIX.7.1 - Print Administration
  39.  
  40. The Printing group is probably the furthest along, since they held a
  41. mock ballot in June.  The base for their document is the Palladium
  42. print system which was originally developed as part of MIT's Project
  43. Athena.  It is now included in the Open Software Foundation's DME
  44. project.  The document specifies print commands, a programming
  45. interface, and a set of managed object definitions. (More on these
  46. later.)
  47.  
  48. Palladium is the reference implementation of the ISO Document Printing
  49. Application Standard (DPA), currently in international ballot as a
  50. Draft International Standard (DIS) under working group ISO/IEC
  51. JTC1/SC18 (The official name of the ISO document is: Information
  52. technology - Text and office systems - Document printing application
  53. (DPA) - Part 1: Abstract-service definition and procedures, September
  54. 1991).  It's a client/server distributed system.
  55.  
  56. One of the reasons for the mock ballot was to determine whether
  57. Palladium was an acceptable choice for a base.  Since lpr and lp (both
  58. the pre-SVR4 and SVR4 versions) are much more widely used, the group
  59. was concerned that their standard would be voted down on
  60. ``not-existing-practice'' grounds.
  61.  
  62. The people in the mock ballot okayed Palladium.  Eleven (11) said
  63. Palladium would be okay, nine (9) said it would be okay if some
  64. changes were made (changes the POSIX.7.1 group then adopted) and only
  65. five (5) were against it.  Astute readers will note that this a small
  66. mock ballot group, but it was at least a well-rounded one with 6
  67. University people, 10 from computer or operating system vendors (NeXT,
  68. IBM, Sequent, USL, Sun, OSF, Intergraph, Fujitsu), and 4 from user
  69. companies (US West, Bellcore, British Telecom, Boeing).
  70.  
  71. The No votes on Palladium were particularly strong however, so the
  72. group is still concerned.  If you have an opinion on this either way,
  73. please contact the author.
  74.  
  75. POSIX.7.2 - Software Management
  76.  
  77. The Software Management group is not far behind the printing group.
  78. The draft document is stabilizing and should go to mock ballot soon.
  79. It includes commands to install and upgrade software packages.  It
  80. also includes managed object definitions, but no API.
  81.  
  82. The base of their standard is HP's swinstall tools and USL's pkg
  83. tools.  Currently, the commands look more like the HP commands, but
  84. that is still in flux.
  85.  
  86. POSIX.7.3 - User and Group Management
  87.  
  88. The User and Group Management subgroup is still in the early stages.
  89. They have been gathering submissions for their base documents, and
  90. have been trying to determine a course of action.
  91.  
  92. There has been some debate about whether User/Group Management is a
  93. mature enough area to standardize, and the POSIX Project Management
  94. Committee (PMC) suggested that this group publish a Guide rather than
  95. a standard.  You can expect these issues to be cleared up in the near
  96. future, and a solid direction to form soon.
  97.  
  98. Managed Objects?
  99.  
  100. All of the POSIX.7 documents are providing descriptions of ``managed
  101. objects'' for their area.  I'm not an expert on this, but here's
  102. everything I know about it.
  103.  
  104. Managed objects are hot in distributed management.  UI's Atlas, OSF's
  105. DME, HP's OpenView, the Object Management Group (OMG) - everyone who's
  106. anyone in the field is using them.  I think they come from network
  107. management, where the ``object'' being ``managed'' was a physical
  108. thing (like a router, for example.)
  109.  
  110. The concept is that there's an object out there, and to do something,
  111. you send it messages.  The Print document, for example, has the
  112. concept of a printer object.  If you want to know what kind of paper a
  113. printer has, you send a message to the printer object and ask for its
  114. ``media-supported'' attribute.  There are objects for print jobs,
  115. software packages, etc.
  116.  
  117. The idea is that these ``managed objects'' work well with distributed
  118. systems because you don't have to know where the printer is - the
  119. message sending mechanism deals with that.  Also, they are an aid to
  120. interoperability, since all POSIX compliant software will have to
  121. support the same set of objects.
  122.  
  123. Road Blocks
  124.  
  125. Fair warning: I'm now going to get up on a soap-box.
  126.  
  127. The next step for the POSIX.7.1 document would seem to be to go to
  128. ballot.  There are, however, two things standing in its way.  First,
  129. all documents need to have test assertions written before entering
  130. ballot.
  131.  
  132. Test assertions are statements about what a function or command does,
  133. written in such a way that someone could easily write a shell script
  134. or program to check that an implementation actually does the correct
  135. thing.  For example: ``If lpr is given the name of a non-existent file,
  136. it returns the following error....'' (There are formatting details
  137. about test assertions, but that's the basic idea.)
  138.  
  139. Although having these test assertions is clearly valuable, writting
  140. them is a tedious, time consuming process, and it is likely to delay
  141. ballot by several meetings.  Also, since many details of the commands
  142. and functions are likely to change during ballot, many of the
  143. assertions will need to be thrown away.
  144.  
  145. Less clearly valuable is the Language Independent Specification (LIS)
  146. of the function calls, which also needs to be written before a draft
  147. goes to ballot.  The functions have to be abstracted from C to an
  148. invented specification format which is free of programming language
  149. dependencies.  The idea of this is to remove any parts of the API that
  150. are implicitly dependent on C syntax, such as return values from
  151. functions, pointer parameters, or the use of structures.  Only the
  152. functionality should remain.
  153.  
  154. The group then writes a companion ``C thin-binding,'' which doesn't
  155. describe what the functions do, it just talks about how the
  156. functionality described in the LIS is implemented in C.
  157.  
  158. I believe the goal of the LIS is to make it easier for people
  159. interested in an Ada or Fortran version of POSIX to write the
  160. appropriate language binding for it.  Again, this is tedious and time
  161. consuming, and will likely eat up several meetings of POSIX.7's
  162. limited resources.
  163.  
  164. Volume-Number: Volume 29, Number 26
  165.  
  166.