Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.24/text0027.txt

Text File | 1991-09-03 | 5.4 KB | 105 lines

Submitted-by: [e-mail] (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:                [phone]
Data Logic                      Fax:                [phone]
Queens House                    Telex:              888103
Greenhill Way                   APIA SprintMail:    C.HARDING
HARROW HA1 1YR                  X/Open E-mail:      [e-mail]
U.K.                            Other E-mail:       [e-mail]


Volume-Number: Volume 24, Number 28