P1003.17

[Shane McCarron]

Submitted-by: ahby at ui.org (Shane McCarron)

> 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.)

Note that the XOM interface is NOT an object management interface
(regardless of what the title says).  It is just a set of interfaces
for manipulating opaque data types across a network of heterogeneous
systems.  If you called it XDR you wouldn't be far from correct.
Certainlky XDR is extensible, so logically XOM could be too.  However,
XOM isn't designed to be extensible, and XDR is.  XOM is designed to
solve an extremely specific problem - and by all accounts it solves
that problem.

> 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!).

I don't understand this contention.  It is impossible to present a
different standard compliant interface  - the language bindings are
the standard, and they are being specified by the committee.  Also,
note that the XOM activity is NOT a POSIX standard.  Frankly, the XDS
activity shouldn't be either, but we haven't fixed taht yet.  XOM is
P1224 - only P1003 committees are POSIX.

> 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.

Again, I don't understand this.  The underlying protocols for XDS are
defined by X.500, so communication between machines will work.  XOM
just provides interfaces to encode C language specific data types in
ways that are compatible across the network (unless I am very much
mistaken - that happens sometimes).

> 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.

XOM will never be promoted as a generalized namespace manager,
especially not for things within POSIX.  It is not a POSIX service.
Generalized namespace management will have to wait for some
interesting consortia based work to mature (e.g. DCE).

-- 
Shane P. McCarron			ATT:	+1 201 263-8400 x232
Project Manager				UUCP:	s.mccarron at ui.org


Volume-Number: Volume 24, Number 15