Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!uunet.UU.NET!sef
From: guthery@ASC.SLB.COM
Newsgroups: comp.std.unix
Subject: P1003.17
Message-ID: <1991Jun19.215832.16006@uunet.uu.net>
Date: 19 Jun 91 11:35:57 GMT
Sender: usenet@uunet.uu.net (UseNet News)
Organization: UUNET Communications Services
Lines: 43
Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix)
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: guthery@ASC.SLB.COM

Andy Hume fairly summarizes part of my objection to the tack that P1003.17 and
P1224 are taking with respect to objects; viz. that vendors can extend whereas
users cannot.  I agree with Andy that extension is not, as Ezno suggests,
"technically infeasible".  Andy points to one possibility.  There are clearly
others.  Lisp and Smalltalk systems have been doing this for years so we know
it can be done. (We're talking existence, folks, not efficiency.)

My other objection was that the XDS/XOM user will be presented with a
different "standard compliant" interface by each vendor *AND* it is left as an
exercise for the user to "impedance match" between them.  This is not a
standard by any definition I know.  The vendor gets to declare POSIX standard
compliance and the the user has been left with the task of defining and
implementing a common interface on top of different vendor-specific
implementations.  Huh?  (Unless, of course, the user only uses one vendor but
in this case we have a degenerate standard ... one thing is always exactly
like itself whatever the thing is!).

Interestingly, P1003.17 and P1224 are being driven by X/Open.  X/Open's
own Long Term Vision states:

	"An environment in which users have access to all of the information
	 needed to carry out their job, without contstraints imposed by
                                        ===============================
	 incompatibility of technology or data."
         =====================================

But, vendor incompatibility is exactly what XOM provides.  Thus, I seems to me
that the base technology that X/Open is trying to hustle through POSIX (XDS
and XOM) violates its own charter never mind the spirit of POSIX.

Actually, I wouldn't be worrying so much if XOM were just a bunch of helper
routines at the bottom of XDS and X.400.  But the fact is that name space
management (threads, files, you name it) is the name of the game.  XOM could
be trotted out as a good way to manage names everywhere in POSIX and indeed it
might be.  But not if it locks names away in lots of little bunkers to which
only the vendors have the keys.

							Cheers, Scott


Volume-Number: Volume 24, Number 14