Xref: utzoo comp.lang.c++:5536 comp.object:420 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++,comp.object Subject: Re: Shippable C++ Objects (RFC) Message-ID: Date: 17 Nov 89 19:00:04 GMT References: <9832@june.cs.washington.edu> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 103 In-reply-to: peterd@cs.washington.edu's message of 16 Nov 89 21:54:49 GMT In article <9832@june.cs.washington.edu> peterd@cs.washington.edu (Peter C. Damron) writes: In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >1. Assume an Event interface between processes. 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? The natural assumption is that if I have a byte stream that represents an object to be sent to another process, I will issue an event to that process that will cause that process to invoke the reconstruction method. My assumption (perhaps invalid) was that all processes are built from the same object library, therefore the object methods are the same in both processes because its the same object class. There has to be some assumptions that the project that both processes are involved in are part of the same effort (in other words, they reuse each others code). >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. Exactly! Except that this write() and read() are to memory instead of to disk (this should give a C++ program more flexibility in what to do with that object). Now the application, not the object, has the choice of where to send the object and how to get it there (this might be wrapped in a higher object). >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. If you want to ship a single node, do you have to ship the whole graph that contains it? Would the node make sense to the receiving process without the object that its next pointer points to? If so, then that comes under the heading of "doesn't need to be shipped" (at least this particular time). However, if you ship a node to another process without the object that is referred to by the node's next pointer (essentially just the data within the node), is it still a node? >7. Memory pointers are the special case. Now this is the hard part. What you want is remote & local references to objects (everything is an object right?). I'm not sure what you mean here. Each process will use the object in its non-shipped, internal form, so to each process the object will be local at the time of its reference. Its up to the application to decide whether there are any conflicts (from a lock standpoint) about this way of doing business. >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. Why? The shippable format only exists during the move of an object from one process to another. Breaking an object down into simple terms for this purpose should make it easier to work with. >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. Since the processes are dealing with the same class of object, then virtual pointers should take care of themselves (they must be right for the particular process). Code cannot be shipped, therefore the implication is that both processes are already compiled with the same code. Since the "linearization" of the object by the method I have suggested deals with each object in an object to be shipped individually, virtual pointers can be safely ignored (they are outside the definition of an object) because each object only deals with what it knows about. Therefore, the callback method via the event type will know what object needs construction and so construct it with the proper virtual functions already there. I suggest you read about systems that have already tried to deal with distributed objects... I'll try, but the company I work for doesn't have ready access to a reference library. 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 -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"