On 29 Dec 2004 14:15:57 -0500, David Bolen <db3l@fitlinxx.com> wrote:
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.
Why's that actually a risk? In any case where a PB app uses Copyable and suchlike, that assumption is made. If someone is marking an exception as jellyable, then they know that their clients should also be able to unjelly that exception, and it will be a part of the protocol.
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).
That's exactly what the patch would do, AIUI. On the server side, you can set unsafeTracebacks if you want tracebacks to be sent to the client. The server side can also set an exception class as jellyable if you want to send exception instances to the client. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | -- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// | -- http://twistedmatrix.com |o O| | Founding Member, Hobart Hacking Society w----v----w-+ -- http://hackingsociety.org/chapters/hash