[Zope-dev] Zope.pipeline proposal

[Tres Seaver]

-----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          tseaver at 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-----