[Twisted-Python] Supporting new types with PB
db3l at fitlinxx.com
Mon Aug 16 10:40:36 EDT 2004
I've been trying to get Perspective Broker to cooperate for the
transmission of mx.DateTime values across a remote session (we use
them for some of our components which are referenceable objects) and
was hoping to solicit input on the simplest or most appropriate way to
A while back we encountered a similar problem with mx.DateTime values
within objects that we were returning from components as copyables.
Back then we "punted" and ended up supporting the concept of pickling
specific fields for the remote copy, thus letting the mx.DateTime
values go through as pickles. But I was hoping to support them more
Originally I was hoping that I could just define mx.DateTime as an
acceptable (type, class, module) in the default security object, but
the problem seems to be that it needs support in the raw jelly layer,
since it's a type in an extension module. I'm guessing that the same
problem would exist with Python's (2.3+) datetime type, since that is
also a new type and not a user class.
So I next figured I'd just augment the jelly layer to add the new
type, but that doesn't look all that clean to do. I really only want
to change jelly, but the default broker uses the jelly module
functions directly. I suppose I could reach in and change the jelly
reference in the broker module but that seems messy.
The one replaceable point appears to be the broker used by the PB
factory. Presumably I could subclass the default broker with one that
overrode the appropriate stuff to use my replacement jelly and in that
replacement jelly handle the extra types prior to deferring to the
default implementation. At least the client is quickly replaceable.
For the server I'd subclass PBServerFactory to override the direct
reference to Broker in buildProtocol, but would otherwise have to cut
'n paste the existing function to maintain behavior, which seems a
I suppose a separate alternative would be to wrap mx.DateTime in my
own classes that implemented Jellyable/Unjellyable, but then I've got
the overhead of running around with my own DateTime wrappers for no
other reason than remote transmission.
Of course, a final alternative is close to what we did previously for
the Copyable problem, and just augment our wrappers on either end to
transform mx.DateTime values into something jelly can handle across
the relevant method calls.
Am I missing something simple? Is there an intended method by which
the existing jelly support in Twisted can be augmented to support
other built-in types rather than only new classes?
More information about the Twisted-Python