-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
>> http://wiki.zope.org/zope3/ZopePipeline > > Thanks for putting this up! In general, I think your goals are very > worthy. I hope we'll end up with more re-usable end/middleware that can > be used by others, including Zope 2 applications like Plone, as a result > of this. Unifying the Zope 2 and Zope 3 publishers a bit more would also > be quite interesting. > > In the proposal, you say: > > "The zope.pipeline project is also working out how to use ZCML and the > Zope component architecture to build a WSGI pipeline that developers can > easily modify to suit their applications." > > I'm used to using Paste Deploy ini files to configure a WSGI pipeline. > Is this simply an alternative to that? If so, do we really need our own > alternative, or could we try to use the Paste Deploy stuff directly? > > I am a little worried about the conceptual overhead of having both the > ZCA and the WSGI pipeline provide "swappability" services to application > builders. It feels like those two things overlap somewhat in scope. Compared to the paste.ini format, I find ZCA + ZCML both too flexible (I don't need type-based lookup) and not flexible enough (I can't configure policy values) for the task of configuring a WSGI pipeline. > Also, looking at your endware, there are some that seem to overlap with > Repoze stuff. Is this on purpose? I think the relationship with Repoze > should be made more clear in the proposal. > > virtual_host -- is this the same as repoze.vhm? repoze.vhm allows two different modes for spelling the virtual host: the "classic" Zope2 spelling, and a spelling which uses extra headers added by the proxy. In both cases, it works by fixing up the WSGI environment such that the "stock" behavior is correct, without requiring the traversal majyk performed by the VHM. > retry -- is this the same as repoze.retry? Probably. repoze.retry allows configuring both the number of retries and the kind of exception in the .ini file. The exception type makes it possible to handle stuff like PostgreSQL's "serialization error" with retry. > create_request -- should this maybe have some compatibility with WebOb > requests? This feature is provided by the "endpoint" machinery in repoze.zope2 and repoze.bfg. > switch_pipeline -- could this be made non-Zope specific? It sounds useful. This might be like the Paste 'composite' / "pants leg" dispatch, or like Routes, depending. repoze.bfg optionally allows using Routes before / in place of traversal from the single root: http://static.repoze.org/bfgdocs/narr/urldispatch.html > log -- both repoze and paste have logging middleware, IIRC repoze just uses the paste logging stuff for the access log. repoze.debug supplies the equivalent of the "big M" / trace log, as well as a postmortem debugger, and the moral equivalent of the Zope2 Control Panel's "Debug" tab. > open_root -- I thought repoze had something similar, but I may be wrong This feature is provided by the "endpoint" machinery in repoze.zope2 and repoze.bfg. E.g., see the probably over-geeral framework in repoze.obob (repoze.zope2 works by supplying a different "helper" to obob): http://svn.repoze.org/repoze.obob/trunk/repoze/obob/publisher.py The repoze.bfg traversal machinery is documented here: http://static.repoze.org/bfgdocs/narr/traversal.html > clean_transaction -- is this not ithe same as repoze.tm2? I can't imagine a need for more than one WSGI middleware integration with the 'transaction' package. Shane's proposal here is for a layer which starts and aborts the transaction at a given layer in the traversal stack: commit would have to happen at another layer further to the "right." I don't know why Shane would split the two apart. > set_site -- sounds useful This feature is provided by the "endpoint" machinery in repoze.bfg; repoze.zope2 just uses the stock traversal-based hook. > event -- also sounds useful; I've had use cases other than setSite() > that require pre- and post-traversal event I actually think that the case for such events is dubious, given that you configure the pipeline yourself, and can thus do the same integration via middleware as you would with events, without the downside of needing to suppress unwanted event handlers. > handle_error -- again, I thought Repoze had something like this repoze.errorlog supplies a Zope-like "error logger" which runs from middleware. You can inspect tracebacks TTW, as with the Zope2 "tool.", but it doesn't live in the ZODB. > end_transaction -- sounds like the other end of repoze.tm2 Again, I don't know why they are split. > authenticate -- sounds like repoze.who? That is certainly the job done by repoze.who. Moving it out to middleware eases sharing authentication across multiple applications. repoze.what is an *authorization* middleware / framework which has been adopted for use in TurboGears2: it extends repoze.who to provide for a quasi-declarative security model for applications. > fix_relative_links -- sounds generally useful outside Zope as well I have written a couple of such bits as one-offs, but never thought I had anything like a general solution. Composability means that we can more easily *avoid* the temptation to generalize prematurely (as with events). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpXPY+gerLs4ltQ4RAt5cAKCp+RTbLilJ5eWZAdsuIW75kw0BWgCg0Vlz Dp03UOd0NomDlSg9yaq7ot8= =JxK8 -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )