Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0073.txt < prev next >

Wrap

Text File | 1991-09-03 | 18.5 KB | 527 lines

- 1 - ------------------------------------------------------------------ Report on the July IEEE POSIX Meeting for EurOpen POSIX is a family of standards which has grown in a hodge- podge fashion since its formal IEEE birth in 1985. It started small with a specific goal in mind, and it can be argued that the need is answered by the POSIX.1 standard otherwise known as ISO/IEC 9945-1. Somewhere along the way, the process grew dramatically. An explosion of projects under the banner of POSIX has created a huge complex entity which everyone expects to fulfill their own diverse needs. Managing this complexity has been pretty informal using seat-of-the-pants discussions until the recent past. Long talked about Committees are being created and are gaining momentum. The management process is being put in place to hopefully co-ordinate this huge volunteer effort of building an industry standard for something as complex as a full function operating system. (By management, I refer to the process co-ordination type, not the suit-and-tie type.) IEEE POSIX meetings now have two very different faces. There is the work group face. Each individual working group has a chair dedicated to the task of preparing a specific draft document to be balloted for eventual acceptance as a standard. Knowledgeable volunteers work in these rooms discussing, editing and arguing the issues for their particular corner of POSIX. Then there's the co-ordination face. Here, also, we are beginning to see an explosion of committees. There are now steering committees dedicated to: - Conformance Testing issues across all projects, - Distributed Services issues across the several working groups involved with network oriented interfaces, - Windowing User Interfaces issues, - Profiling issues within POSIX, and their relationship to profiles at large. The Project Management Committee (PMC) is a subcommittee of the Sponsor Executive Committee (SEC). The SEC is the guiding force behind the IEEE's Technical Committee on Operating Systems m Standards Subcommittee (TCOS-SS). TCOS-SS is responsible for Operating Systems standards. The PMC reviews new project requests (PARs) and checks on the status of current working group projects. - 2 - A new Ad Hoc Committee began meeting in Santa Clara to discuss the fundamental issues of ``a POSIX architecture.'' What does this ``thing'' look like? Will the Security extensions to ISO/IEC 9945-1:1990 (POSIX.1) work together with the Real-Time extensions? What happens when the Transparent File Access extensions are added to the picture? Here we cover the recent IEEE POSIX working group meeting from the co-ordination point of view, tracking events across the projects instead of covering the individual projects from within. The Project Management Committee July's meeting was the second set of working meetings of the PMC. This group is still getting used to its role as a project reviewer and scrutinizer of new project authorization requests (PAR). PARs are created for each draft document in the process. Once a PAR has been passed by the PMC, and accepted for sponsorship by the TCOS-SS SEC, it arrives at the IEEE's Standards Advisory Board for final and formal acceptance as a work item for a working group. The PMC suffered the same malaise the rest of POSIX projects suffer at times. People were extraordinarily busy with their ``real employment'' between the April and July meetings. Many of the reviews of existing projects which were scheduled for this meeting weren't done. The mentor for POSIX.0 (POSIX Guide) completed her review of the project. POSIX.0 has become real. It began initially as a working group of people with a higher level of concern for POSIX. It was the group holding discussions about how POSIX would be used in a more global sense, rather than minute examination of the nitty-gritty individual function calls or language bindings. POSIX.0 isn't building a document for standardization, but rather an overall guide to Open Systems Environments. It was through this group's efforts that the Profiles Steering Committee was born. The POSIX.0 document is now being strongly lobbied for acceptance as an ISO Technical Report. Many issues which have been left to rest for quite some time now, are all rearing up again. It was assumed when the group was formed, that the other working groups would automatically provide the liaison people to ensure the models in the Guide were accurate. This did not happen. The PMC reported on this lack of involvement and took steps to get the SEC to ensure there is adequate - 3 - review of the Guide by other working groups. The participation of working groups was also demanded in the discussion about architecture framework. This will hopefully see action at the next IEEE POSIX meeting in October. The one new PAR reviewed by the PMC at this meeting was the request from POSIX.5 (Ada Bindings) for a project to address POSIX real-time extensions. This work passed the PMC with some minor word-smithing, and is discussed later. Language Independence Specifications Programming language independent specifications (LIS) are a requirement placed on the IEEE POSIX working groups by ISO. The current and future C based functional interfaces will eventually be described semantically in an LIS and with various different programming language bindings associated with each. A language independent specification of POSIX.1 and its C binding (POSIX.16) now exist. These documents will shortly go out for mock ballot. A mock ballot is useful for finding remaining problems with a document prior to being sent for real ballot. For comparison reasons POSIX.1/LIS, POSIX.16 and the ANSI C standard should be equivalent to the existing ISO 9945-1 standard. The ballot period will hopefully be 45 days, starting early August. The mock will be sent to the POSIX.1, POSIX.5, POSIX.9 mailing lists, but it is an open ballot. It was suggested that the TCOS-SS Programming Language Independent Specification Guidelines should also be added to the ballot since readers may find something they consider incorrect, and is pervasive in the documents because it is due to a particular method or guideline from the Methods document. General ballot instructions include: - determining the equivalence of the new LIS and C Binding to the existing 9945-1, (remember, 9945-1 cannot be broken); - determining if the LIS and C Binding clearly relate; - determining whether the split of material between the LIS and C Binding is a coherent one, and - 4 - - determining how easy it is to produce another language binding to the the LIS. There are still many questions to be answered with the LIS work. Conformance specifications for the LIS and the nature of test methods are much talked about issues. The validity of the current object model for LIS and the lack of an event model are problems to be addressed. Interoperability is still not addressed formally. Hopefully, the mock ballot will contribute to all of these areas. The other POSIX language bindings, Ada (POSIX.5) and FORTRAN-77 (POSIX.9), are still proceeding with their ballot resolution process. ISO/IEC JTC1/SC22/WG15 has accepted the POSIX.5 and POSIX.9 position of finishing their current ballot and producing language bindings to future LIS in the revised ISO languages once all of those documents exist and are stable. Current drafts were circulated at the May WG15 meeting for review and comment. New Zealand has proposed building a Modula-2 binding to POSIX.1 as a work item to ISO. Within the POSIX working groups there is a new wrinkle with the LIS work. POSIX.12 (Protocol Independent Interfaces) is proposing to do two bindings to an as yet undefined LIS one for BSD sockets, and one for X/Open's Transport Interface (XTI). Two language bindings to the same LIS isn't unusual. They just happen to be in the same language! A lot of this has to do with two established bodies of experience unable to compromise, and attempting to arrive at a creative solution. I don't believe that they've really thought it through. Harmonizing the functionality in the two existing C bindings to an independent specification will be non-trivial and possibly infeasible. If the functionality is completely covered by the LIS and the two bindings wholly overlap, why are they not harmonizing the interfaces? Another twist is the interoperability question between two language bindings. People often use the example of one program running in one process context written in one language which writes a pipe, should be understood by a different program in a different process context written in a different language reading the pipe. I don't think the intent here is that a program using sockets will communicate directly to a program written to use XTI. - 5 - Profiles Steering Committee July was the first working meeting of the Profiles Steering Committee (PSC). The fledgling group is attempting to wrestle with a gargantuan task. They seem torn between trying to sort out the possibly limited and thorny problems of POSIX profiles, versus helping to solve the world's profiling and frame work problems. That is a somewhat naive statement, based on my narrow view of what a profile could be, and should understandably be taken liberally salted. The first meeting became somewhat mired in liaison issues with the rest of the world. They were fortunately able to pull out of this mode and formed two small working groups to address two specific problems. One small group dealt with the harmonization of terminology across various different groups working both inside and outside of POSIX. The second group dealt with formulating the rules by which POSIX profiles are built. Both of these groups made good progress during the rest of the week. Ada Real-time Study Group The POSIX Ada working group (POSIX.5) wants to begin building a binding to the POSIX.4 Real-time Extensions. They received permission to start a study group at the April meeting, and had a project request formally approved at this meeting. The new project, christened POSIX.5a (Ada Binding to POSIX.4), is under the direction of the current POSIX.5 working group. The group is not extending the Ada language for real-time capabilities. They are binding to the currently defined POSIX.4 interface definitions. The ``thick'' binding versus ``thin'' binding issue has been put off. A language independent specification of POSIX.4 does not yet exist. The group will continue in their current process of building usable documents for programmers. The group recognizes that there is a co-ordination issue with ISO for both SC22/WG9 (Ada) and for the current proposed work item for Real Time Ada Extensions (ISO/IEC JTC1 N1266, dated 1991-02-22). This is the ExTRA (Extensions Temps Re'el a` Ada ...) work from AFNOR, the French member body of ISO. As yet, ISO has not assigned sponsorship for this work item. - 6 - GUI Wars Revisited _W_e'_r_e _b_a_a_a_a_c_k ... For the second meeting running, discussion was dominated by the two opposing direct ballot project requests for an Open Toolkit Environment (Open Look) and a Modular Toolkit Environment (OSF/Motif). These projects had been rejected ``at this time'' at the April meeting in Chicago. A letter from Paul Borrill (vice-president for standards in the IEEE Computer Society, and a member of the IEEE Standards Board) forced the re-opening of the issue. The letter was seeking reasons for rejection and stated that two standards in the same project space was not sufficient reason to reject the requests. A subcommittee was formed early in the week to summarize all of the discussions that took place at the April meeting. After many meetings and much writing, the subcommittee delivered its report at Thursday evening's SEC meeting. The SEC members were asked if they agreed with any of the statements (pro and con) contained in the sub-committee's report. The majority of the statements were against acceptance of the PARs. Many SEC members had many problems with accepting the two PARs. This is how the motion to sponsor both PARs failed. A quick straw poll demonstrated that many people felt there was a fundamental problem with the projects. These problems would not go away with some rewording or re-organization of the PAR. It was readily acknowledged that the documents could not move forward as direct ballot documents. This was a fast track option to be used with non-controversial documents. Clearly not the case here. This should have been used in April as the stopping point! A real vote was then taken and the motion to sponsor the projects failed. People barely caught their breath when a motion to remove sponsorship from P1201 was made. (You could have heard a pin drop ...). The rationale is that P1201 was supposed to be developing a standardized toolkit for windowing and clearly suffers from the same fundamental flaws as the two defeated project requests. P1201 has been moving ahead for several meetings, working to an unrecognized project scope. The working group has been attempting to come up with a ``virtual'' toolkit for windowing, under which Motif or Open Look could be plugged. Indeed, they claim anything could be plugged into the new model, including a MacIntosh or Presentation Manager - 7 - interface. They have made substantial progress the past two meetings working with the XVT specification as a base document, probably because former supporters of Motif and Open Look have been busy with their own project requests. Now they face complete termination. This removal of sponsorship effects P1201.2 (Recommended Drivability Practise) as well. The motion to remove the P1201 sponsorship has been tabled until the October meetings. The Project Management Committee was due to review this project for the October meeting anyway, so it was felt they should be allowed to do their job first. What this really means is that yet another meeting is going to be turned on end with discussions of standardization of windowing interfaces. Institutional Representative Voting Issues A subcommittee of the Sponsor Executive Committee (SEC) recently balloted the TCOS Operating Procedures. In general there is nothing too controversial in them, with one notable exception. The vote is being removed from TCOS SEC Institutional Representatives (IR). It is a sensitive enough issue that it is separately called out in a mini-ballot all by itself. The mini-ballot phrasing was slanted towards removing the vote, and has already been attacked on the net. Apparently history is the culprit here. It's always easy to blame history. It's never there to defend itself. The concept of IR was created within the IEEE standards arena with the intent of allowing other accredited standards organizations to have representation. TCOS extended the IR role to include X/Open, USENIX and Uniforum. It looks good to be able to point to the greater acceptance of a standard by the technical community this way. Other groups applied for this status. There was a small proliferation of IRs within the SEC. A concern was raised over the growing numbers of ``outside'' votes being generated. With no good definition in the IEEE standards hierarchy as to what exactly an IR is, there's no way to limit the number. The results of the mini-ballot will be interesting. I personally objected on my ballot, arguing that IRs have a voting role and that the rules should be modified to adequately define IRs. All of the IRs can be reviewed in the light of the new definition. There are already rules in - 8 - place to remove IRs. IRs often have a broader picture of POSIX than individual working group chairs, intent on their own working group progress and problems, and therefore add to the process. +--------- --------------------------------------------------------------------+ Stephen R. Walli SRW Software phone: (416) 579 0304 572 Foxrun Court, fax: (416) 571 1991 Oshawa, Ontario, Canada, speaker!stephe@mks.com -OR- L1K 1N9 uunet!watmath!mks!speaker!stephe +--------- --------------------------------------------------------------------+ Volume-Number: Volume 24, Number 74