Xref: utzoo comp.lang.c++:5547 comp.object:426 Path: utzoo!utgpu!watmath!att!rutgers!ucsd!usc!cs.utexas.edu!rice!uw-beaver!uw-june!peterd From: peterd@cs.washington.edu (Peter C. Damron) Newsgroups: comp.lang.c++,comp.object Subject: Re: Shippable C++ Objects (RFC) Summary: think some more Message-ID: <9832@june.cs.washington.edu> Date: 16 Nov 89 21:54:49 GMT References: Reply-To: peterd@june.cs.washington.edu.cs.washington.edu (Peter C. Damron) Organization: University of Washington, Computer Science, Seattle Lines: 108 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >... I'd like to get some comments (please post) on the following ideas for >the shipment of C++ objects between processes (and, by implication, the >persistence of the object). >1. Assume an Event interface between processes. Therefore, when shipping an >object, you can be very sure that something on the other side (in this case, >a callback) will understand what it is because of the event type. How does the event type relate to the object type/class? How do you assure that the object methods are the same in both processes? I assume that the different processes are in different address spaces. >2. Assume each class of objects has methods for building a shippable byte >array representation of the object ... >3. Assume each class of objects has methods for filling (or constructing) >itself from the shippable byte array representation made in (2)... It sounds to me like you are implementing write() and read() in 2 & 3. >4. All parts of an object must be handled in (2) and (3), even to the point >of just deciding that part of an object doesn't need to be shipped. >Therefore, even memory pointers must be resolved in the processing of (2) and >(3). If you want to ship a single node, do you have to ship the whole graph that contains it? >7. Memory pointers are the special case. In the process of encountering a >memory pointer, converting to shippable form seems to require a need for a >symbol table... Now this is the hard part. What you want is remote & local references to objects (everything is an object right?). >9. Reconstructing the object on the other side would mean nothing more than >copying well-known values from the byte stream into their proper places and >doing some special tracking of pointer symbols in the byte stream to make sure >they get relinked properly... It sounds like you are limiting the shippable format to be an LL(0) language. This may be too restrictive. >10. If the methods for build_shippable() and init_from_shippable() are >virtual on the object, then object type for the shippable form will have to be >correct even if the object referred to when build_shippable() is invoked is of >pointer to parent type. Because the object type will be correct, then the >proper event callback on the other side will get invoked. How do you represent virtual pointers accross processes? I get the feeling you thought about data but not code. I suggest you read about systems that have already tried to deal with distributed objects, like Eden and Emerald here at University of Washington. Try the references below for starters. Hope this helps, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd --------------- %T Distribution and Abstract Types in Emerald %A Andrew P. Black %A Norman C. Hutchinson %A Eric Jul %A Henry M. Levy %A L. Carter %J IEEETSE %V 13 %N 1 %D JAN 1987 %T Fine-Grained Mobility in the Emerald System %A Eric Jul %A Henry M. Levy %A Norman C. Hutchinson %A Andrew P. Black %J TOCS %D FEB 1988 %T Replication in Distributed Systems: The Eden Experience %A Jerre D. Noe %A Andrew Proudfoot %A Calton Pu %J PROC Fall Joint Computer CONF (FJCC) %C Dallas, TX %D NOV 1986 %P 1197-1208 %T The Architecture of the Eden System %A Edward D. Lazowska %A Henry M. Levy %A Guy T. Almes %A Michael J. Fischer %A Robert J. Fowler %A Stephen C. Vestal %J PROC 8th SYMP on Operating Systems Principles %D DEC 1981 %P 148-159