Gary Poster wrote:
I worked on a Zope-2.9 branch of off the CVS HEAD for zasync this week. It over there: http://svn.nuxeo.org/trac/pub/browser/vendor/zasync/branches/z29-nux/
awesome!
The customer is currently testing out an application using it so it's supposed to work. What remains to be done is porting the tests (which sounds like a big deal looking at the non standard tests there...)
I don't know. I was definitely experimenting. :-/ And the "tests" of the client don't deserve the name. I plan to do much better with the new version.
Note, this branch is using an "in house" persistent queue replacing the BTrees within the zasync manager.
Cool.
Of course, I'd like to put this branch back to the zope.org repository but please not in CVS... I don't feel courageous enough to branch and merge with CVS anymore...
:-)
Would it be possible to migrate the zasync component from the cvs.zope.org to svn.zope.org ? I don't know who can do that ? (Hopefully, we'll have a ZF soon...)
I don't care about migrating the history, so if noone else does either I could try doing a migration.
ok go ahead then. I'll fix the tests just before.
Gary, it would be an occasion to check you persistent queue and see how we could add this to ZODB and make zasync use it.
Cool. Yes, I'll try to get the persistent queue in ASAP. I have a few small changes, and then I need to make the test changes that Florent suggested.
great.
Other question : how people would feel about an integration of zasync, or another implementation, into the Zope core ?
The functionality is certainly very, very useful for large sites (and for any site that needs big work done on demand, I guess). I wonder if the configuration approach I took makes it too heavy for the core, though. Certainly, this was a first generation, and there are a number of things I wish I had done differently, beyond better tests: I started writing them down here, in the beginning of what I plan to be a Zope3-based rewrite (largely ZODB-based, hopefully, rather than too many dependencies on Zope 3; we'll see): http://svn.zope.org/Sandbox/poster/zope.zasync/README.txt?view=auto
Zope 2 isn't WSGI/Twisted yet, is it?
nope not yet.
The zasync rewrite (which I'm working on occasionally personally now, and will need at work in a couple of months) might work pretty well in Five if the Twisted reactor is used in Zope 2. If not, maybe someone knowledgeable in Medusa could write an equivalent. Finally, maybe others have a zasync approach that would be a better choice.
Within a month or so I hope to put up a proposal for the zasync rewrite so folks can comment on it and see if it's going a direction they like (or see if they can push me in a direction they like :-). I am hopeful that it will feel "lighter" than the current implementation.
Alternatively, if there's an effort by other folks to write another approach entirely, cool!
ok let's wait for your proposal to discuss about it. Sounds great. You can expect us to get involved since we're having a huge need of zasync for a while now. zasync works fine for now on our side (and deeply overloaded here on production instances ;) Apart from the BTrees conflicts errors we had, that are fixed now with the persistent queue. Cheers, J. -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66