home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0049.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  14.2 KB  |  279 lines

  1. Submitted-by: stephe@mks.uucp (Stephen Walli)
  2.  
  3.  
  4.  
  5.            Report on the January 1992 IEEE POSIX Meeting for EurOpen
  6.                        Stephen R. Walli <stephe@mks.com>
  7.                       EurOpen Institutional Representative
  8.  
  9.  
  10.           Standing  on Huntington  Beach,  gazing across  the  moonlit
  11.           Pacific  after  a  five  hour  Sponsor  Executive  Committee
  12.           meeting, is a  small group of  POSIX refugees.  It is 10 pm.
  13.           The  oil  rigs  glow  golden  in  the  distance  like  great
  14.           Christmas trees.  The surf crashes and hisses at our feet.
  15.  
  16.           Jason:  Just  remember,  Stephe,  in  the  grand  scheme  of
  17.           things....
  18.  
  19.           Stephe [interrupting]: ...Oil's important.
  20.  
  21.           Okay. So  I'm  a cynic.  It  was generally  an ugly week.  I
  22.           believe  there  are  still  some  fundamental flaws  in  the
  23.           structure  of  POSIX.   Working  group  members   are  still
  24.           grappling with  the  enormity of  the  beast we've  created.
  25.           GUIs, rescued from  the jaws of defeat by the IEEE Standards
  26.           Advisory Board,  entered the scene  again. Life (and  POSIX)
  27.           goes on.
  28.  
  29.           1.  POSIX is coming! POSIX is coming!
  30.  
  31.           The IEEE  POSIX  working groups ARE  coming to Europe.  This
  32.           Autumn, the POSIX working groups will be meeting in Utrecht,
  33.           NL, from  October 19-23.  The meetings will  be held at  the
  34.           Holiday Inn and the Scandic Crown Hotel.
  35.  
  36.           Information will be  posted to this  column, and on  the net
  37.           where appropriate, as the meetings approach.
  38.  
  39.           There will  also be an  ISO Working Group  15 (WG15 --  ISO
  40.           POSIX) meeting around  the same time.  It will either be the
  41.           week before or  the week after,  and will also be in Europe.
  42.           Again, information will be forthcoming.
  43.  
  44.           2.  SICC and the PMC
  45.  
  46.           POSIX often  makes  use of  the fact that  a small group  of
  47.           people can  go off  and accomplish what  a large group  will
  48.           spend hours  arguing  about. Small  committees are the  work
  49.           method  of  choice  in many  areas.  Two committees  of  the
  50.           Sponsor Executive Committee  (SEC) are the System Interfaces
  51.           Co-ordination Committee (SICC),  and the Project  Management
  52.           Committee (PMC).
  53.  
  54.           SICC is gaining  momentum. It is  effectively the chairs  of
  55.           all the system interface groups:
  56.           -- POSIX.1, the base system interface,
  57.           -- POSIX.4, real-time extensions to POSIX.1,
  58.           -- POSIX.6, security extensions to POSIX.1,
  59.           -- POSIX.8, transparent file access extensions to POSIX.1,
  60.           -- POSIX.12,  protocol  independent   interfaces  (Berkeley
  61.             sockets and X/Open's TLI).
  62.           -- POSIX.15, supercomputing batch interfaces,
  63.           -- POSIX.17, directory services (think X.500).
  64.  
  65.           They are  a simple  subcommittee of the  SEC, that meets  to
  66.           resolve areas of conflict between the base standards, and to
  67.           work out concerns which affect all of the documents.
  68.  
  69.           The other group  which is effecting  the way POSIX is coming
  70.           forward is the  Project Management Committee (PMC). This was
  71.           the fourth  meeting  the PMC  has existed,  and half of  its
  72.           eight members  were due  to retire. Two  elected to stay  on
  73.           (and were voted  back in by  the SEC) for  an additional two
  74.           year  term.  Two  new  members  (one  of  them  the  EurOpen
  75.           Institutional  Representative,)  were  also voted  into  the
  76.           group.
  77.  
  78.           The PMC  is responsible for  mentoring existing projects  to
  79.           ensure they are  performing according to plan. They are also
  80.           responsible for  ensuring that  new project requests  (PARs)
  81.           are complete and  have all the  attendant paper work  before
  82.           reaching the SEC.
  83.  
  84.           One interesting  result  of their  work  this week  was  the
  85.           splitting up of the POSIX.7 (System Administration) project.
  86.           POSIX.7 has been re-organized into:
  87.           -- a parent project (POSIX.7), which is responsible for co-
  88.             ordinating the other parts of the POSIX.7 standard
  89.           -- POSIX.7a to build a standard for print management,
  90.           -- POSIX.7b to build a standard for software management,
  91.           -- POSIX.7c to a set of guidelines for user management.
  92.  
  93.           The final subproject  is important. There  is not sufficient
  94.           agreement  on  how  to do  user  administration to  build  a
  95.           standard.  There  is   a  lot  of   existing  practice  with
  96.           administering  users.  Everyone   agrees  that  the  current
  97.           solutions are not good. So they are building a set of agreed
  98.           upon guidelines. It's  really too bad  the PMC didn't  exist
  99.           when other project requests were cut to suggest this sort of
  100.           solution for  certain  other contentious  immature areas  of
  101.           technology.
  102.  
  103.           3.  Multi-lingual Test Assertions
  104.  
  105.           Multi-lingual Test Assertions are test assertions written in
  106.           such  a  way   that  test  suites  in  multiple  programming
  107.           languages  could be  written.  This addresses  the  problems
  108.           associated with  testing conformance  for something like  an
  109.           Ada run-time  environment,  that supports  POSIX.5 (the  Ada
  110.           language version  of  POSIX.1 functionality,)  when all  the
  111.           test suites are written in C.
  112.  
  113.           POSIX describes an  interface to operating  system services.
  114.           It is  based  on the  historical  C interface  to UNIX,  but
  115.           should not  be  restricted to  just  that language.  No  one
  116.           wants  to  make  the  same  mistakes  made with  GKS  (which
  117.           demonstrated  you  could   write  Fortran  programs  in  any
  118.           language,) by forcing other languages to bind the interfaces
  119.           in the same functional way.
  120.  
  121.           This  was  why  ISO WG15  (ISO  POSIX) wants  a  programming
  122.           language independent specification to be written of POSIX.1.
  123.           Other   languages   can    then   bind   the   functionality
  124.           appropriately. The semantic  description would be  kept in a
  125.           single book, with the appropriate syntactic binding and glue
  126.           in other books.
  127.  
  128.           Test  assertions written  to  POSIX.1 demonstrate  the  same
  129.           problems.  Everyone  agrees  that  much  of  the  functional
  130.           content of the  test methods for  POSIX.1 should be the same
  131.           no matter what  programming language is  being used to write
  132.           the suite.  If the test assertions from which the test cases
  133.           are  built   were  written   to  the  programming   language
  134.           independent version of  the standard, they could be bound to
  135.           the language  syntax  at the  same  time as  the  functional
  136.           specification, providing a  language based set of assertions
  137.           from which to build the conformance test suite.
  138.  
  139.           Okay. The  cat's out  of the bag.  We are really  discussing
  140.           language independent  specification  test assertions.  If  I
  141.           used that  as  the title  to  this section,  you might  have
  142.           turned the page.  Hopefully, you now at least appreciate the
  143.           problem to be  solved, even if  you still run screaming into
  144.           the night.
  145.  
  146.           Now all  we have to  do is solve  the resource problem,  and
  147.           find people to help with the specification.
  148.  
  149.           4.  Distributed Security Study Group
  150.  
  151.           A group  of  about twenty  people met for  a day during  the
  152.           January  POSIX  meeting   to  discuss  distributed  security
  153.           technologies and scenarios. The group felt it had sufficient
  154.           momentum and manpower to form a proper study group, and they
  155.           will  meet for  the  entire week  at  the April  meeting  in
  156.           Dallas, TX.
  157.  
  158.           They were a little disorganized to begin with, but agreed to
  159.           a set  of  existing specifications and  models they wish  to
  160.           begin investigating at the next meeting.
  161.  
  162.           There are those within the group that wish to take some time
  163.           to  investigate  the   current  base  of  experience  before
  164.           proceeding,  while   others  appear  to   want  to  pick   a
  165.           specification and begin  tweaking it into a standard. Pretty
  166.           aggressive considering  they haven't  cut a project  request
  167.           yet!
  168.  
  169.           5.  PAR Wars II -- The Umpire Strikes Back
  170.  
  171.           Since we  last  looked in  on  our story, our  protagonists,
  172.           OSF/Motif  and  Open  Look  (sometimes  known as  Rodan  and
  173.           Godzilla) were off  chasing their project requests (PARs) up
  174.           the IEEE Standards hierarchy. Having been told ``no'' by the
  175.           Sponsor Executive Committee  (SEC), they are  now asking for
  176.           sponsorship  at  the  higher  level  of the  IEEE  Standards
  177.           Advisory Board (SAB).
  178.  
  179.           You will recall the flow.
  180.           -- April 1991,  the  PARs first surface.  The intent is  to
  181.             directly  form  ballot   groups  to  ballot   the  current
  182.             programmers   and   users   guides.   The   SEC,   clearly
  183.             uncomfortable with the  obvious overlap between  these two
  184.             GUI PARs and the current work in P1201, argues for several
  185.             hours (!) and then tables discussion at that time.
  186.  
  187.           -- July 1991, discussion is re-opened. A small committee is
  188.             formed to  clearly  state all  pros  and cons  of the  two
  189.             projects. The presentation  is made, and since all members
  190.             of the  SEC  find at  least one  serious problem with  the
  191.             Motif and  Open  Look project  requests, the projects  are
  192.             voted down.
  193.  
  194.             Some were concerned  over the apparent lack of maturity of
  195.             the  technology.    No   one  that   has  tried  the   two
  196.             technologies (with  the exception  of the PAR  presenters)
  197.             seems  to  like  either  of  the  interfaces.  People  are
  198.             concerned that  wrapping a standard  around them now  will
  199.             prevent them  from being improved  and matured. Some  user
  200.             representatives clearly wish  there to be a single unified
  201.             standard.
  202.  
  203.             With the apparent ``death'' of the two competing PARs came
  204.             a motion  to  remove sponsorship  from the existing  P1201
  205.             project, arguing it  suffers the same flaws. Discussion is
  206.             tabled to  the  project management  committee (PMC)  until
  207.             October.
  208.  
  209.           -- October 1991,  P1201 is allowed  to survive. P1201.1  is
  210.             making good progress  at defining a higher level interface
  211.             for simple  windowing,  based on  current practice.  While
  212.             possibly not  as  functional as either  the Motif or  Open
  213.             Look  toolkits,  it   is  useful  to   a  wide  range   of
  214.             applications, and  there is  consensus forming around  it.
  215.             P1201.2 is  preparing a  recommended practice document  on
  216.             windowing style, and is making good progress.
  217.  
  218.             The  Motif  and  Open  Look  projects presenters  are  off
  219.             haunting other corridors  (SAB).  The SAB, pointing to the
  220.             802 LAN standards  as if they were a ``good'' example, has
  221.             said it  is  an insufficient  reason  to kill the  project
  222.             requests simply because they have overlapping scopes.
  223.  
  224.           The SEC is  responsible for approving  projects for the IEEE
  225.           Technical  Committee  on  Operating  Systems  --  Standards
  226.           Subcommittee (TCOS-SS).  This  is where  POSIX  and the  GUI
  227.           standards all reside.
  228.  
  229.           It seems  the  SAB is  sympathetic to  their plight and  has
  230.           agreed to  sponsor  the projects.  Gone are the  contentious
  231.           ideas that the  two camps will  directly form ballot  groups
  232.           and  ballot the  current  programmers references  and  users
  233.           guides.  The SAB has said that they must play fair, and play
  234.           by the rules.  (Direct balloting only  exists on paper  as a
  235.           method of fast-tracking clearly uncontentious documents.)
  236.  
  237.           The SAB has  further offered them  BACK to TCOS-SS/SEC!  The
  238.           projects really DO  belong within the scope of TCOS. The SEC
  239.           agreed to take  a look at the revised sponsored-in-principle
  240.           projects at the  April 1992 meeting.  I believe one member's
  241.           phrase was to  ``accept the pig  in a poke  now, and rip the
  242.           bag off later.''   Hopefully, it won't  be too prophetic  an
  243.           analogy.
  244.  
  245.           We have been  cautioned that we  can not trivially  agree to
  246.           accept them, then  shut them down. They have been sponsored-
  247.           in-principle  by  a higher  power.   The two  projects  have
  248.           already each  held their first  meetings, outside of  TCOS's
  249.           sphere of influence.
  250.  
  251.           I for  one  want to see  them really play  by the rules!  If
  252.           accepted  by  TCOS,  they  should  certainly come  into  the
  253.           Steering  Committee  on  Windowing User  Interfaces  (SCWUI)
  254.           realm of  influence.  No reason  to  exempt them  from  test
  255.           assertions either.
  256.  
  257.           Language  independent  specifications  (LIS)  are  certainly
  258.           appropriate considering  the number  of Ada developers  that
  259.           currently need to find messy solutions to working with these
  260.           two GUIs in  their native Ada environments. Indeed, they may
  261.           discover that they  functionally overlap more than they care
  262.           to admit by  writing the LIS.   If they rationalize the LIS,
  263.           as POSIX.12 is  doing with C-based  sockets and C-based XTI,
  264.           then maybe  Ada  could benefit  by coming  up with a  single
  265.           binding standard!
  266.  
  267.           Of course,  if  they were  to  come forward  as  recommended
  268.           practices or guidelines,  instead of as  full use standards,
  269.           they would not  need to provide  LIS and test  assertions as
  270.           robustness proofs.  Something to think about.
  271.  
  272.           As  I  said  at  the  end of  the  last report,  ``thus  are
  273.           standards born.''
  274.  
  275.  
  276.  
  277. Volume-Number: Volume 27, Number 49
  278.  
  279.