I have a Perspective <-> Referenceable server/client setup, and am trying to pass objects between them. Following the online docs I've set all the relavent classes to inherit from pb.Copyable + pb.RemoteCopy, and passed them all to pb.setUnjellyableForClass.
I'll take responsibility for that one (I wrote those docs :). If the classes behave the same way on both ends, then it can make sense to inherit from both Copyable and RemoteCopy. If objects are supposed to behave differently depending upon whether they are the "home" or the "away" form, then you'll want two classes, where the "home" form is pb.Copyable and the receiving "away" form is pb.RemoteCopy. Often this depends upon whether the object really has a home: if it is just a container for some chunk of state, and doesn't hold any references to other objects, then it doesn't really have a home and you can use the dual-inheritance trick to cut down on some typing. In particular classes which could be replaced by dictionaries without losing any functionality fall into this category. You still have to keep in mind that the setCopyableState method is the point where you get to exercise security. The 'state' provided to this method comes from malicious invaders intent upon compromising your application. Make sure it can deal with whatever evil it is given.
I'm also unsure what to make of the last bullet under "Things To Watch Out For" on the above webpage. It seems unsure whether using __init__ to initialize transferable objects is ok... Must I truly go and hack all my objects to not use __init__, and instead use setCopyableState()?
To be precise, the received objects are created with a hack that creates an object of a dummy class, then transforms it into the correct class, then runs setCopyableState to populate the attributes. By doing this, it avoids running the new class' __init__ method altogether. When the object is created by you (by using the class name as a callable), it will run __init__. When it is created in response to a received serialized instance, it will not run __init__ but will run setCopyableState instead. This lets you set up objects differently in the two different situations.
The "module not allowed" exception is misleading, and stems from what appears to be an obsolete branch "else" branch of jelly._Unjellier.unjelly(), judging by the fact that it uses the temp variable jelType for something different than the "if" branch.
I think you might be right. We have a review of PB scheduled for the PyCon sprint next tuesday.. I've added that code to the list of stuff to be examined. We'll try to clear out all the dead code on that day. cheers, -Brian