POSIX.17

[Chris Harding]

Submitted-by: cjh at datlog.co.uk (Chris Harding)

I participate in the POSIX .17 work as technical editor and previously
participated in the production of the base document from which the 
POSIX standard is being derived. I am concerned that some of the comments
which I understand Scott Guthery recently posted to comp.stds.unix may 
give the wrong idea of what is going on and would like to set the record 
straight.

Scott seems to have two objections:
    
    1)  that the "object management" mechanism used by the emerging P1003.17
	and P1224 standards is extensible by vendors but not by users

    2)  that these standards do not effectively constrain the vendor, so 
	that the user must "impedence match" between different (but
	still compliant) implementations.

Although the first of these objections is untrue as stated, there is a 
valid point behind it. I will come to this later. The second objection,
however, is not only wrong but is arguing against a feature which, rather 
than limiting the user, actually makes the API more "open".

Let me justify this last statement. 

The movement towards "open" systems arose largely from the desire of users 
not to be "locked in" to vendors' proprietary implementations. The concept 
evolved of an "open" system as one in which there was a standard interface 
to applications programs.  An applications program written to this interface 
would then be portable between different vendors' systems and the user would 
no longer be "locked in". 

But this, the original "open systems" concept, is actually somewhat naive, 
since it (implicitly) assumes that the user will just buy one system and 
write one application program to run on it. What he really wants to do is 
to buy several different systems and also buy - from several different
vendors - several different software packages to run on them. The concept 
of "open" system must be expanded to address these needs.

The "object management" mechanism used by P1003.17 and P1224 
(it isn't really anything to do with Object Management in the sense of
Smalltalk etc. and use of the phrase is a bit confusing) provides a 
standard representation of information that can be used by different 
software packages running on the same system. It also allows for the fact 
that different implementations may include different options from the
same standard (and how many standards are there that don't have any
options?) and for the fact that a software package may be released in
several versions, each with different features (and how many software
packages are there that don't have several versions? - only the 
unsuccessful ones where nobody bought the first version). In fact, it
really addresses the issues that arise when trying to run different 
software packages (possibly from different vendors) on a single system. 

It is in this sense that the emerging P1003.17 and P1224 standards are
more "open" than most "open systems" standards and, far from limiting
the users, are really giving users much more freedom of choice.

Although they provide this extra flexibility, it is not true to say
that the emerging P1003.17 and P1224 standards fail to constrain the
implementation properly. They define behaviour on which the application 
can rely. They force the implementation, where it provides a feature, to
provide it in an exactly and unequivocally specified way. In short,
they do constrain the implementation in the way that standards should.

Coming back to the first objection, the point at issue is, who can extend
the classes of object used by P1003.17 and P1224? The answer is, and
sensibly can only be, that the standards bodies responsible for defining
P1003.17 and P1224 are the only people who can extend them in a way that
is binding on the whole community of vendors and users. 

Having said this, either a vendor or a user may also extend these classes 
to describe a proprietary feature (in the case of a vendor) or a specific 
requirement (in the case of a user). It is true that vendors are more 
likely than users to make such extensions but there is nothing in the 
methodology that would prevent a user from doing so. So (for example) the 
Military might introduce some new classes of object if it wished to define 
a special version of the X.400 API for Military use. 

The valid point behind the objection is that the "object management" 
methodology used by P1003.17 and P1224 does not have a "class" concept
with the properties of extensibility enjoyed by the "class" concepts
of Smalltalk and some other languages. This is a fair criticism.
However, the methodology does have (as I have tried to show above) 
other properties which Smalltalk classes do not have and which are 
far more valuable in the context of the sophisticated "open-ness" 
requirements with which we now have to deal. Although it is an elegant
feature, a real need for "extensibility" has yet to be demonstrated.
Let's get the "open-ness" requirements sorted out first. 
Perhaps "extensibility" can be added later.

Regards,

Chris
-------------------------------------------------------------------------
Chris Harding                   Tel:                +44 81 863 0383
Data Logic                      Fax:                +44 81 861 2010
Queens House                    Telex:              888103
Greenhill Way                   APIA SprintMail:    C.HARDING 
HARROW HA1 1YR                  X/Open E-mail:      c.harding at xopen.co.uk
U.K.                            Other E-mail:       cjh at datlog.co.uk


Volume-Number: Volume 24, Number 28