[Twisted-Python] A proposal for simple remote object editing (Twisted and ZODB integration)

[Jean-Paul Calderone]

On Wed, 28 Jun 2006 03:31:56 +0900, Robert Gravina <robert at gravina.com> wrote:
>I'd just like to throw out an idea after working with Twisted  (especially 
>Perspective Broker) getting the early stages of my  application going over 
>the last few weeks.
>
>I love object databases... I've been using ZODB because it's so  simple to 
>work with, no SQL, just create your Python classes and all  their attributes 
>(dictionaries, references to other objects) will be  pickled for you and 
>saved in a file (or database, never tried it  though)...
>
>Anyhow, I've started writing my Twisted application, where clients  contact 
>a server to get objects, edit their details, and send them  back. Because 
>ZODB works by maintaining references to other objects,  I can't just replace 
>them with the new Copyables  when they come back  because they are different 
>instances. So, I compare the _p_oid  attribute (object ID) with my original 
>objects to locate the one I'm  looking for, copy the __dict__ across from 
>the Copyable to the  original object, and commit the transaction. I haven't 
>gotten much  further than that, but I'm sure I'll have problems with objects 
>which  refer to other objects etc.
>
>What's great about Referenceables is that Twisted gives you the  original 
>instance when they come back to you, but the client can't  access the 
>attributes or run any of it's methods locally. What's  great about Copyables 
>is that the whole instance is sent down the  wire and the client can alter 
>it's attributes, call it's methods, and  send it back...
>
>Back to the ZODB... what would be extremely useful is if clients  could get 
>an objects from the ZODB sent down to them, edit the  attributes and call 
>the methods, and sent it back and *have it be the  original instance again*. 
>Sort of like the best of both words of  Referenceables and Copyables. Of 
>course, this doesn't have to have  anything to do with the ZODB, it was just 
>my motivation for this  idea. Any object could be sent down the wire, 
>edited, and sent back  having the original instance updated.
>
>My questions are:
>
>1) Is there any way to achieve this using Twisted the way things are?

It's possible for applications or libraries which use Twisted but aren't
part of Twisted to define new kinds of behavior for PB objects.  You can
define a class which combines the features of Referenceable and Copyable
if you like.

You can find some code which does something somewhat along these lines in
twisted/words/service.py: for example, the PBGroup and PBGroupReference
classes cooperate to make a type which, on the remote side, ends up with
Python methods which make remote PB method calls as well as a single
data attributes copied from the server (the attributes are effectively
read-only, though - you cannot modify them and send the instance back to
the server).

>
>2) Is my copying-across-the-dict a good enough solution, and I should  just 
>forget about the whole thing?

If the possibility for multiple clients to interact with the same objects
simultaneously exists, you will need some kind of conflict resolution.
This is one reason Twisted doesn't include a class like this - different
applications often want different conflict resolution behavior.

>
>3) I hear Zope 3 contains some kind of Twisted integration. For the  life of 
>me I can't find any information about this on the web, and I  even bought a 
>book on Zope 3 recently and the only reference to  Twisted is that you can 
>use Twisted Web instead of Zope's ZServer to  service web requests.

The integration is by way of WSGI.  While this means that Zope3 code may
be running in the same process as a Twisted reactor, you have to go a bit
out of your way to get any benefit from this.

>
>4) I've been toying with Divmod Axiom, and I see there is Twisted  Persisted 
>(but can't find much info on it), plus there is Twisted  Enterprise, but 
>that is too close to relational databases for my  liking. Do any of these 
>projects have integration like this?

None of them do.

>
>5) Does anyone else think this is a cool idea and like to see it 
>implemented?

It might be interesting.  I can't see any use-cases for which it is head
and shoulders above a solution with looser PB coupling, but that doesn't
mean one doesn't exist. :)

Jean-Paul