On Tue, 2002-04-30 at 12:05, Kevin Turner wrote:
I've got an arrangement where the obvious way to do things is with a Viewable...
only, it turns out that some of the "who"s don't really need to be in a seperate process from the Viewable; storageView is actually a reference to a ViewPoint instead of a *remote* reference to a ViewPoint, and ViewPoints don't have callRemote (because, well, they're not remote).
The reason that this isn't automatic is because PB has the option to *do* stuff when you send state to other people (such as tracking the fact that they have said state). In most simple cases, such as yours, it's not necessary to completely replicate PB's object-copying semantics; however, this sort of short-cut for simplicity's sake is not something the framework can make a decision about for you; trying to run certain kinds of remote code locally would break it. (Think about P2P applications that try to connect to each other by determining the other end of the connection's IP) The reason I introduced callRemote was to facilitate this sort of thing. Since the only message you expect your object to respond to is "callRemote", simply implement "callRemote" on a pseudo-ViewPoint, (similarly to twisted.spread.util.LocalAsRemote -- maybe LocalAsViewPoint?)
I don't know, maybe PB just isn't quite as transparent as I desire it to be. I did so much like the idea of writing this code to communicate locally now, and just being able to drop in remote objects instead later.
PB isn't supposed to be transparent. I think I've made my argument against transparency before, but it boils down to what I said above; sometimes, transparency is wrong. In the cases where it's not, it's easy to fake using Twisted. -- | <`'> | Glyph Lefkowitz: Travelling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |