andrew@alice.att.com (Andrew Hume) (06/17/91)
Submitted-by: andrew@alice.att.com (Andrew Hume) The latest login; has three (!) reports on the january 1991 meeting of P1003.17 and P1224. In particular, I was interested in the object management PAR and the controversy that aroused two additional articles. The problem is that I can't quite figure out what the problem really is. Perhaps if I go through what I think is going on, then someone will correct me. XDS and X.400 defines objects and their encodings via ASN.1. (This latter means that the BNF-like specifications of the objects is written in the ASN.1 syntax and that there is a corresponding well defined encoding into a byte stream.) There is some grouping of these objects into ``packages'' (I don't know what this means or implies). XDS and X.400 define an interface for accessing these objects. That is, a byte level encoding of commands mixed with objects. I think the 1003.17 work is about defining multiple ``versions'' of these interfaces, with the idea that each version might be a value-added or extended interface. so far, so good. Scott complains (rightly) that it sucks that vendors can extend these packages and that users can't. Enzo doesn't say whether he agrees but says that it seems technically infeasible. Could someone comment whether this is a fair summary? My initial take on this is that it may be technically infeasible to dynamically support new objects but this should have been a goal of the work until conclusively shown to be infeasible. (It actually isn't anyway; it is easy to see how new objects could be handled as long as you were willing to pay a performance hit for the new objects. It can be done by analyzing the byte stream interpretively rather than with compiled code; again, just for the new objects). andrew hume andrew@research.att.com Volume-Number: Volume 24, Number 11
guthery@ASC.SLB.COM (06/19/91)
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 14ahby@ui.org (Shane McCarron) (06/20/91)
Submitted-by: ahby@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@ui.org Volume-Number: Volume 24, Number 15