[Twisted-Python] Re: More on PB Copyable Errors

David Bolen db3l at fitlinxx.com
Wed Dec 29 14:15:57 EST 2004


Justin Johnson <justinjohnson at gmail.com> writes:

> Attached is a patch with modifications to pb.py and jelly.py.  With
> the patch applied, CopyableFailure.getStateToCopy first checks to see
> if the actual exception instance's class has an unjellyable registered
> so it can be unjellied on the other side.  If it does, the actual
> exception instance is passed back as failure.value.  Otherwise a
> string representation is passed back as it is today.

I think the one big risk with this approach is that I'm not sure a
sender can ever know accurately whether a recipient will be able to
unjelly a particular instance.  In your case, you're assuming the two
sides are symmetrical and have imported the same definitions, but that
need not be the case.  At least in general, it's certainly possible
for the transmitting side to not have the unjellier registered (if it
never expects to receive such objects back, for example).  Or
conversely, the sender may have an unjellier registered but the
recipient won't.  In this latter case you'd get an exception on the
remote side which sending the string would have avoided.

One alternative approach to handle this is to transmit both the string
and instance representation, and then let the decoding side trap any
unjellier security exceptions and fall back to the string
representation.  The big question of course is whether such a fallback
should be automatic, silent, etc..

Another option would be to provide some sort of configurability
(perhaps something along the lines of how unsafe traceback support is
handled) so an application could make the choice of what mode to
operate in, either string names, or full instances (and the latter
just has to have unjelliers registered just as for any other remotes).

I'm sort of in the same state you are in, in that for me the simplest
approach is just transmit the instance because my two sides are in
fact symmetric.  So the short internal change to local source works
fine for me too.  But I think that any general addition to the twisted
base needs to take the more general proposition (and issues) into account.

-- David





More information about the Twisted-Python mailing list