[PEAK] PEAK and Twisted, revisited

Stephen C. Waterbury golux at comcast.net
Thu Apr 15 16:59:53 EDT 2004

Hi Ulrich,

You wrote:

> in PEAK you use the EventDriven Component as App-Component (or
> subclasses of it) instead of Twistd. peak.event.Tasks are then
> scheduled in the TwistedReactor that can use async io/deferreds

Is there any example (preferably non-web) code for this?
In particular, my application uses the usual Twisted chains of
callbacks/errbacks ... have these been implemented or
experimented with in a PEAK context?

Also, I've been looking at your nll.database.sqldm,
and it looks like it has a lot of what I would need.  How close
is it to being usable?  I don't necessarily need stability (my
code is evolving, too, and I've been using Twisted for 2 years
now, so that says something about my tolerance for the bleeding
edge ;).  I notice several items in your TODO.txt, such as
bringing it up to date with the latest changes to PEAK ... does
that apply to nll.database.sqldm?

I currently use Twisted's adbapi, and I don't see anything in
PEAK like it (doesn't mean it's not there, of course ;).  It can
use psycopg as its wrapped DBAPI driver, so might somehow
be made to work with some existing peak.storage module.
Any suggestions on how best to integrate it into a PEAK

The application I'd like to port to PEAK has an architecture like:

Client                     |      |Server
------                     |      |------
Domain  /Log-\ / XMLRPC or\|wire, |/X \ /Log-\ /Services  \
Objs<->| ical |  SOAP or   |------| S  | ical |(Repository,|
|       \API / \ PB/Banana/|ether,|\PB/ \API / \ etc.)    /
Local            (etc)     |etc   |(etc)
Persistence                |      |
(ZODB)                     |      |

I apologize for the crudity of this model ...
(Back To The Future fans:  identify this quote! :)

Nothing particularly earth-shaking or original here,
of course -- this is just to provide context for my questions.

Since we're currently using XML-RPC, I use a very simple transfer
of state using dicts (xmlrpclib maps these to structs, of course, so
that part is transparent).  We have a local "registry" that supervises
serialization/deserialization, making sure local instances are unique,
and the most important domain objects are explicitly versioned
(new version => new instance), with versioning being managed by the
Repository service and understood by the client.

I'm thinking a possible approach might be to implement the logical
Repository API as a layer that would sit on top of a collection of
datamanager API's -- perhaps an IVersioningDM that extends IWritableDM,
and an ISQLQueryDM ...?  The serialization API's for XML-RPC, SOAP, and
PB could be backends to it on the client, frontends on the server.
Does that make sense in PEAK API-space?

Thanks in advance (and for all the help so far :).


More information about the PEAK mailing list