[Twisted-Python] Problems with PB and Jelly...

[Brian Warner]

> 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