home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: stephe@mks.uucp (Stephen Walli)
-
-
-
- Report on the January 1992 IEEE POSIX Meeting for EurOpen
- Stephen R. Walli <stephe@mks.com>
- EurOpen Institutional Representative
-
-
- Standing on Huntington Beach, gazing across the moonlit
- Pacific after a five hour Sponsor Executive Committee
- meeting, is a small group of POSIX refugees. It is 10 pm.
- The oil rigs glow golden in the distance like great
- Christmas trees. The surf crashes and hisses at our feet.
-
- Jason: Just remember, Stephe, in the grand scheme of
- things....
-
- Stephe [interrupting]: ...Oil's important.
-
- Okay. So I'm a cynic. It was generally an ugly week. I
- believe there are still some fundamental flaws in the
- structure of POSIX. Working group members are still
- grappling with the enormity of the beast we've created.
- GUIs, rescued from the jaws of defeat by the IEEE Standards
- Advisory Board, entered the scene again. Life (and POSIX)
- goes on.
-
- 1. POSIX is coming! POSIX is coming!
-
- The IEEE POSIX working groups ARE coming to Europe. This
- Autumn, the POSIX working groups will be meeting in Utrecht,
- NL, from October 19-23. The meetings will be held at the
- Holiday Inn and the Scandic Crown Hotel.
-
- Information will be posted to this column, and on the net
- where appropriate, as the meetings approach.
-
- There will also be an ISO Working Group 15 (WG15 -- ISO
- POSIX) meeting around the same time. It will either be the
- week before or the week after, and will also be in Europe.
- Again, information will be forthcoming.
-
- 2. SICC and the PMC
-
- POSIX often makes use of the fact that a small group of
- people can go off and accomplish what a large group will
- spend hours arguing about. Small committees are the work
- method of choice in many areas. Two committees of the
- Sponsor Executive Committee (SEC) are the System Interfaces
- Co-ordination Committee (SICC), and the Project Management
- Committee (PMC).
-
- SICC is gaining momentum. It is effectively the chairs of
- all the system interface groups:
- -- POSIX.1, the base system interface,
- -- POSIX.4, real-time extensions to POSIX.1,
- -- POSIX.6, security extensions to POSIX.1,
- -- POSIX.8, transparent file access extensions to POSIX.1,
- -- POSIX.12, protocol independent interfaces (Berkeley
- sockets and X/Open's TLI).
- -- POSIX.15, supercomputing batch interfaces,
- -- POSIX.17, directory services (think X.500).
-
- They are a simple subcommittee of the SEC, that meets to
- resolve areas of conflict between the base standards, and to
- work out concerns which affect all of the documents.
-
- The other group which is effecting the way POSIX is coming
- forward is the Project Management Committee (PMC). This was
- the fourth meeting the PMC has existed, and half of its
- eight members were due to retire. Two elected to stay on
- (and were voted back in by the SEC) for an additional two
- year term. Two new members (one of them the EurOpen
- Institutional Representative,) were also voted into the
- group.
-
- The PMC is responsible for mentoring existing projects to
- ensure they are performing according to plan. They are also
- responsible for ensuring that new project requests (PARs)
- are complete and have all the attendant paper work before
- reaching the SEC.
-
- One interesting result of their work this week was the
- splitting up of the POSIX.7 (System Administration) project.
- POSIX.7 has been re-organized into:
- -- a parent project (POSIX.7), which is responsible for co-
- ordinating the other parts of the POSIX.7 standard
- -- POSIX.7a to build a standard for print management,
- -- POSIX.7b to build a standard for software management,
- -- POSIX.7c to a set of guidelines for user management.
-
- The final subproject is important. There is not sufficient
- agreement on how to do user administration to build a
- standard. There is a lot of existing practice with
- administering users. Everyone agrees that the current
- solutions are not good. So they are building a set of agreed
- upon guidelines. It's really too bad the PMC didn't exist
- when other project requests were cut to suggest this sort of
- solution for certain other contentious immature areas of
- technology.
-
- 3. Multi-lingual Test Assertions
-
- Multi-lingual Test Assertions are test assertions written in
- such a way that test suites in multiple programming
- languages could be written. This addresses the problems
- associated with testing conformance for something like an
- Ada run-time environment, that supports POSIX.5 (the Ada
- language version of POSIX.1 functionality,) when all the
- test suites are written in C.
-
- POSIX describes an interface to operating system services.
- It is based on the historical C interface to UNIX, but
- should not be restricted to just that language. No one
- wants to make the same mistakes made with GKS (which
- demonstrated you could write Fortran programs in any
- language,) by forcing other languages to bind the interfaces
- in the same functional way.
-
- This was why ISO WG15 (ISO POSIX) wants a programming
- language independent specification to be written of POSIX.1.
- Other languages can then bind the functionality
- appropriately. The semantic description would be kept in a
- single book, with the appropriate syntactic binding and glue
- in other books.
-
- Test assertions written to POSIX.1 demonstrate the same
- problems. Everyone agrees that much of the functional
- content of the test methods for POSIX.1 should be the same
- no matter what programming language is being used to write
- the suite. If the test assertions from which the test cases
- are built were written to the programming language
- independent version of the standard, they could be bound to
- the language syntax at the same time as the functional
- specification, providing a language based set of assertions
- from which to build the conformance test suite.
-
- Okay. The cat's out of the bag. We are really discussing
- language independent specification test assertions. If I
- used that as the title to this section, you might have
- turned the page. Hopefully, you now at least appreciate the
- problem to be solved, even if you still run screaming into
- the night.
-
- Now all we have to do is solve the resource problem, and
- find people to help with the specification.
-
- 4. Distributed Security Study Group
-
- A group of about twenty people met for a day during the
- January POSIX meeting to discuss distributed security
- technologies and scenarios. The group felt it had sufficient
- momentum and manpower to form a proper study group, and they
- will meet for the entire week at the April meeting in
- Dallas, TX.
-
- They were a little disorganized to begin with, but agreed to
- a set of existing specifications and models they wish to
- begin investigating at the next meeting.
-
- There are those within the group that wish to take some time
- to investigate the current base of experience before
- proceeding, while others appear to want to pick a
- specification and begin tweaking it into a standard. Pretty
- aggressive considering they haven't cut a project request
- yet!
-
- 5. PAR Wars II -- The Umpire Strikes Back
-
- Since we last looked in on our story, our protagonists,
- OSF/Motif and Open Look (sometimes known as Rodan and
- Godzilla) were off chasing their project requests (PARs) up
- the IEEE Standards hierarchy. Having been told ``no'' by the
- Sponsor Executive Committee (SEC), they are now asking for
- sponsorship at the higher level of the IEEE Standards
- Advisory Board (SAB).
-
- You will recall the flow.
- -- April 1991, the PARs first surface. The intent is to
- directly form ballot groups to ballot the current
- programmers and users guides. The SEC, clearly
- uncomfortable with the obvious overlap between these two
- GUI PARs and the current work in P1201, argues for several
- hours (!) and then tables discussion at that time.
-
- -- July 1991, discussion is re-opened. A small committee is
- formed to clearly state all pros and cons of the two
- projects. The presentation is made, and since all members
- of the SEC find at least one serious problem with the
- Motif and Open Look project requests, the projects are
- voted down.
-
- Some were concerned over the apparent lack of maturity of
- the technology. No one that has tried the two
- technologies (with the exception of the PAR presenters)
- seems to like either of the interfaces. People are
- concerned that wrapping a standard around them now will
- prevent them from being improved and matured. Some user
- representatives clearly wish there to be a single unified
- standard.
-
- With the apparent ``death'' of the two competing PARs came
- a motion to remove sponsorship from the existing P1201
- project, arguing it suffers the same flaws. Discussion is
- tabled to the project management committee (PMC) until
- October.
-
- -- October 1991, P1201 is allowed to survive. P1201.1 is
- making good progress at defining a higher level interface
- for simple windowing, based on current practice. While
- possibly not as functional as either the Motif or Open
- Look toolkits, it is useful to a wide range of
- applications, and there is consensus forming around it.
- P1201.2 is preparing a recommended practice document on
- windowing style, and is making good progress.
-
- The Motif and Open Look projects presenters are off
- haunting other corridors (SAB). The SAB, pointing to the
- 802 LAN standards as if they were a ``good'' example, has
- said it is an insufficient reason to kill the project
- requests simply because they have overlapping scopes.
-
- The SEC is responsible for approving projects for the IEEE
- Technical Committee on Operating Systems -- Standards
- Subcommittee (TCOS-SS). This is where POSIX and the GUI
- standards all reside.
-
- It seems the SAB is sympathetic to their plight and has
- agreed to sponsor the projects. Gone are the contentious
- ideas that the two camps will directly form ballot groups
- and ballot the current programmers references and users
- guides. The SAB has said that they must play fair, and play
- by the rules. (Direct balloting only exists on paper as a
- method of fast-tracking clearly uncontentious documents.)
-
- The SAB has further offered them BACK to TCOS-SS/SEC! The
- projects really DO belong within the scope of TCOS. The SEC
- agreed to take a look at the revised sponsored-in-principle
- projects at the April 1992 meeting. I believe one member's
- phrase was to ``accept the pig in a poke now, and rip the
- bag off later.'' Hopefully, it won't be too prophetic an
- analogy.
-
- We have been cautioned that we can not trivially agree to
- accept them, then shut them down. They have been sponsored-
- in-principle by a higher power. The two projects have
- already each held their first meetings, outside of TCOS's
- sphere of influence.
-
- I for one want to see them really play by the rules! If
- accepted by TCOS, they should certainly come into the
- Steering Committee on Windowing User Interfaces (SCWUI)
- realm of influence. No reason to exempt them from test
- assertions either.
-
- Language independent specifications (LIS) are certainly
- appropriate considering the number of Ada developers that
- currently need to find messy solutions to working with these
- two GUIs in their native Ada environments. Indeed, they may
- discover that they functionally overlap more than they care
- to admit by writing the LIS. If they rationalize the LIS,
- as POSIX.12 is doing with C-based sockets and C-based XTI,
- then maybe Ada could benefit by coming up with a single
- binding standard!
-
- Of course, if they were to come forward as recommended
- practices or guidelines, instead of as full use standards,
- they would not need to provide LIS and test assertions as
- robustness proofs. Something to think about.
-
- As I said at the end of the last report, ``thus are
- standards born.''
-
-
-
- Volume-Number: Volume 27, Number 49
-
-