zc.async (was Re: [Zope3-dev] Re: Zope 2 clock server for Zope 3)

[Gary Poster]

On Aug 21, 2006, at 10:51 AM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Christian Theune wrote:
>> Florian Lindner wrote:
>>> Am Sonntag, 20. August 2006 06:11 schrieb Christian Theune:
>>>> Hi,
>>>>
>>>> you might try a look at the recently released zc.async which  
>>>> allows you
>>>> to leverage twisted asynchronous handling together with persistent
>>>> objects (as far as I know right now, haven't looked at it  
>>>> personally
>>>> yet).

First off, thanks to everyone for looking and talking about zc.async  
already.  I have not announced the new collection of zc.* releases  
for a few remaining cleanup reasons (and because I'm mostly away from  
the 'net till Wednesday).  When I do, zc.async will be clarified as  
alpha software--working, exciting, pretty-well-tested software, but  
software that is still under significant development (a bit farther  
than zc.relationship was when we released that, but similar in that  
they both were released while still in-flight to stable).

>>> I've overflown the readme and it looks rather complicated compared
>>> with the Zope2 clock server which is pretty straightforward.

I'm sorry to hear it looks complicated--at least to use.  A  
significant design goal is to have this a lot easier to use and set  
up than zasync was (not a difficult goal, sadly).  In any case, once  
I announce beta, I certainly would appreciate feedback on what could  
be made easier to use.   "[queue].put(callable)" is a common-case  
spelling to get something done, so I'm hopeful that it will be easier  
than perhaps it seemed.  The docs will hopefully be significantly  
improved by then as well.

That said, the clock server is undeniably simpler in architecture and  
design.  For a number of use cases, I imagine some folks will find it  
a nicer solution to use.  zc.async has a different set of primary use  
cases, and arguably covers some hard cases that other solutions don't  
contemplate.

>> Well, it's not exactly the same use case and it's more generic AFAIU.
>
> ...
>  *and* it requires that you run Twisted.

True.  Mostly. ;-)  You could run public-facing app servers on  
ZServer, and worker servers connected with ZEO running Twisted.  But  
yeah, a worker currently needs to run Twisted.

That said, the new design can support a different worker/engine pair  
implementation without replacing too much.  An optional Medusa-based  
worker/engine pair probably would be relatively easy, and would  
verify and enforce the factoring I want for the design.  It might  
only support thread-based jobs, rather than reactor jobs.  After  
beta, when I'll request more feedback, if folks are actively  
interested in a Medusa engine for zc.async, they can probably  
convince me to write it if they convince me they are serious about  
using it.

Anyway, thanks again for the press. ;-)  I'll introduce/announce the  
new stuff late this week.  I wish I had time to do eggs/zc.buildout/ 
PyPI stuff by then, but that will hopefully come eventually.

Gary