[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
application?
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 :).
Cheers,
Steve
More information about the PEAK
mailing list