[Repoze-dev] Fwd: DRAFT: Invitation to a dance

Fri Sep 28 23:23:36 UTC 2007

Darn, forgot to cc the list.

Begin forwarded message:

> From: Chris McDonough <chrism at plope.com>
> Date: September 28, 2007 7:21:04 PM EDT
> To: Philipp von Weitershausen <philipp at weitershausen.de>
> Cc: Christian Theune <ct at gocept.com>, Martijn Faassen  
> <faassen at startifact.com>, Jim Fulton <jim at zope.com>, Ian Bicking  
> <ianb at colorstudy.com>, "Phillip J. Eby" <pje at telecommunity.com>,  
> Rob Miller <ra at burningman.com>, Joel Burton <joel at joelburton.com>,  
> Martin Aspeli <optilude at gmx.net>, Graham Dumpleton  
> <graham.dumpleton at gmail.com>
> Subject: Re: DRAFT:  Invitation to a dance
>
> On Sep 28, 2007, at 5:04 PM, Philipp von Weitershausen wrote:
>
>> My talk at PloneConf revolves around Plone's exit strategies into  
>> a Zope3/WSGI/Paste/... world. Can I mention repozo? I'd hate to  
>> steal your thunder, so I'll be happy to keep quiet about it. But  
>> it seems like such a perfect fit.
>
> I think that'd be great.  Paul was also toying with the idea.
>
>> I actually had the same idea, but I went further and tried using  
>> zope.publisher. That has several advantages, because  
>> zope.publisher is already WSGI-aware and quite pluggable. I got  
>> reasonably far, in such that I could render the ZMI (but without  
>> security). My work is here: http://svn.zope.org/Sandbox/philikon/ 
>> five.publication/. It's a buildout and should therefore be  
>> reproducible for anyone who wants to try out.
>
> Yup, looks familiar. ;-)  We had a 22nd-level goal (not very  
> important at all, IOW) of letting people create "obob" plugins  
> without needing to know anything about the Zope component  
> architecture, so that's why it's the way it is currently.
>
>> The buildout fetches Zope 2 completely via eggs, by the way.  
>> They're available on download.zope.org. I haven't bothered making  
>> them "official" on the CheeseShop yet. Perhaps they could make the  
>> 'zopelib' tarball obsolete in the future?
>
> Can you point me at a URL for the package(s)?  We'd love to be able  
> to get out of that business. ;-)
>
>> You say you have work planned for Zope3 and Grok. I'm quite  
>> surprised that there's so much to do here. If you look at  
>> zopeproject's generated code, you'll see that Zope 3 is pretty  
>> much there already for Paste deployment. Perhaps it could use a  
>> bit more integration into repozo, I suppose.
>
> That's good.  I'm not sure there's much to do there, because the  
> installers for repoze.zope2 and repoze.plone are just for  
> convenience, they aren't meant to represent any sort of suggestion  
> or competition to any "real" build system.  So really it would just  
> be somebody getting a sandbox up and going and *maybe* trying to  
> change the publisher to reuse some of the middleware we've made  
> (repoze.tm, repoze.vhm {which still needs Zope3 support}).
>
>> I took a closer look at your zope.server integration. A lot of the  
>> code you have is already in zope.server. I recently made sure it  
>> has all the necessary WSGI variables (that was a bugfix to the  
>> 3.4.x line) and then I added a PasteDeploy-style entry point  
>> (that's a feature, so it's in the 3.5.x line). Just so you know...
>
> Thanks.  We were developing against a baseline of Zope 2.10.4, so  
> once we have a Zope 2 that has this stuff in it, we can get rid of  
> the server.
>
>> I love the way you factor some things like virtual hosting out of  
>> the application into a middleware.
>
> I'm sure lots of other people have made similar things; we cadged  
> some of the idea from one of Ian's blog posts.
>
>> I'm more skeptical about things like transactions, but I suppose  
>> it would make it easier for non-Zope applications.
>
> There's a bit of precedent for this sort of thing.
>
> http://www.djangoproject.com/documentation/transactions/
>
> http://pythonpaste.org/module-paste.transaction.html
>
> But yes, this is more a feature that makes it possible to use the  
> 'transaction' module in non-Zope applications a bit more easily.
>
>>
>> I'm quite impressed by the mod_wsgi integration. I need to try  
>> this again. How does it deal multithreadedness and interpreter  
>> boostrap?
>
> This story is not nearly as cooked as the "development sandbox" or  
> "pure python server" story.  There's still a lot of figuring out to  
> do here.  I played around and found that mod_wsgi can be configured  
> to run programs in a mode a lot like fastcgi, where it starts up  
> processes that don't live "inside" Apache; you can sort of turn  
> knobs up and down for number-of-threads and number-of-processes for  
> each one of these (I must admit I don't quite understand the number- 
> of-threads parameter yet), as well as which user the process should  
> be started as (which is very handy).  For http://www.repoze.org/tmp/ 
> plone, the configuration is:
>
> WSGIPythonExecutable /home/repoze/tmp/site/bin/python
> WSGIDaemonProcess tmp threads=1 processes=4 maximum-requests=10000
>
> <Directory /home/repoze/tmp/site/etc>
>   Order deny,allow
>   Allow from all
> </Directory>
>
> <VirtualHost *:80>
>   DocumentRoot /home/repoze/www/www.repoze.org
>   ServerName www.repoze.org
>   ScriptAlias /viewcvs "/usr/lib/cgi-bin/viewcvs.cgi"
>   ServerAdmin repoze-dev at repoze.org
>   WSGIScriptAlias /tmp /home/repoze/tmp/site/etc/zope2.wsgi
>   WSGIProcessGroup tmp
>   WSGIPassAuthorization On
>   SetEnv HTTP_X_VHM_HOST http://www.repoze.org/tmp
> </VirtualHost>
>
> In any case, it does run, but we don't have much information on  
> stability nor do we have a truly well-understood configuration  
> yet.  It's a bit of a limitation that you can't specify a  
> WSGIPythonExecutable per virtual-host (and thus not need to do any  
> PYTHONPATH or sys.path munging),  and because the Paste pipeline  
> doesn't seem to be created until the first request, it can take a  
> while for the site to "settle down" once it comes up (it might take  
> 30 seconds to render a single image at first startup time, because  
> it's boostrapping a process).
>
>> So, go WSGI! I think this is a fantastic thing. You guys have done  
>> some great work. I think we can easily iron out some of the edges.  
>> Also, it'd be fantastic if Zope3, Grok, Zope2 could all have  
>> similar stories here. I certainly can see how a repoze-driven Zope  
>> 2 sandbox could be generated by zopeproject.
>>
>
> Right on! ;-)
>
> - C
>

_______________________________________________
Repoze-dev mailing list
Repoze-dev at lists.repoze.org
http://lists.repoze.org/mailman/listinfo/repoze-dev