Xref: utzoo comp.lang.c++:5554 comp.object:432 Path: utzoo!attcan!uunet!snorkelwacker!apple!sun-barr!newstop!east!helium!db From: db@helium.East.Sun.COM (David Brownell) Newsgroups: comp.lang.c++,comp.object Subject: Re: Shippable C++ Objects (RFC) Summary: sounds like RPC systems to me ... Keywords: distribution, RPC, XDR Message-ID: <1044@east.East.Sun.COM> Date: 17 Nov 89 15:49:20 GMT References: <31.UUL1.3#5109@pantor.UUCP> Sender: news@east.East.Sun.COM Reply-To: db@helium.East.Sun.COM (David Brownell) Followup-To: comp.lang.c++ Organization: Sun Microsystems, Billerica MA Lines: 62 In article <31.UUL1.3#5109@pantor.UUCP> richard@pantor.UUCP (Richard Sargent) writes: > >> From: cimshop!davidm@uunet.UU.NET (David S. Masterson) >> Subject: Shippable C++ Objects (RFC) >> >> 3. Assume each class of objects has methods for filling (or constructing) >> itself from the shippable byte array representation made in (2). ... > >Here's the nub of the problem! The rest of the proprosal is quite >straight forward. In fact, I believe that I read a paper on this >in one of the OOPSLA or C++ Workshop proceedings. It's also, surprise!, essentially the same idea that shows up in networking for how to serialize and deserialize RPC arguments. Commercial implementations of the idea (not in C++) include XDR, ASN.1, and an analogue that NCS's NIDL compiles into (sorry, I forget the name). If you've never looked at RPC systems before, do so -- you'll find that they look very much like distributed object systems. (Sun's RPC has a limitation of one object per type per system, but then again any OO programmer worth his/her salt can implement objects that manage access to many other objects ... like NFS does for "file" objects, for example.) >"The object can reconstruct itself from the byte stream" requires >that the object already exist. It still seems to me that you *have* >to have a case statement somewhere which knows about all (interesting) >object classes. The cases create each new type of object, probably using >a class constructor which has a ByteStreamRepresentation argument. Sort of; "object" is distinct from a data format. The process is taking data in one format from one data store into another, and constructing a NEW object by binding methods to the new data representation. What's shipped is data, not data plus code, and the new methods might not implement the class used by the message sender. The key points are needing to use a constructor function, and needing to choose which of several constructors to use. No application will be able to understand all types/classes ... they get incrementally added to real systems over time. Apps need to be able to reject or ignore message types they can't understand by examining a type code stored early in the message; there's a "default" branch in that case statement! >The created object is then added into the receiving program's >organization. How to do this from a general purpose class library >without encoding knowledge of the application is another (lesser) >problem. One interesting trick, irrelevant to today's C++, is to ship source code implementing the class (including its deserializing code) to the message recipient when it needs it. This is what NeWS does, and probably some other systems I don't know about. (I can't see any reasonable networked implementation of Lisp not supporting this, for example!) This still doesn't get away from needing to know the type of the message ("source code followed by data"). David Brownell db@east.sun.com Sun Desktop Systems Software sun!suneast!db Billerica, MA