[Zope-dev] Zope.pipeline proposal

[Shane Hathaway]

Martin Aspeli wrote:
> 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?

Yes, you can just use Paste Deploy instead of the ZCML-based pipeline 
builder.  However, the pipeline you get with Paste Deploy will not vary 
according to the request type, so you won't get the publisher's special 
handling for non-browser methods like PUT and DELETE, nor XML-RPC 
support, etc.

OTOH, I'm sure people can find creative ways to make Paste Deploy vary 
the pipeline according to the request type.

> 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.

They do overlap, but the ZCA-configured pipeline can easily vary 
according to the request type.  I need to add more info about this to 
the proposal.

> 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.

I don't know what the relationship is yet because I've chosen to only 
get code from Zope, for now, since I'm trying to maintain compatibility.

> virtual_host -- is this the same as repoze.vhm?

Could be.  Not sure.

> retry -- is this the same as repoze.retry?

I think it might be different, because this version of retry resets the 
environment rather than the request.  It has to be in the pipeline 
before the create_request application.  This design makes it possible to 
eliminate the complex retry code from Zope requests.

> create_request -- should this maybe have some compatibility with WebOb 
> requests?

I've looked at WebOb, and my impression is that Zope requests and WebOb 
requests serve completely different purposes.  A Zope request is 
essentially an input decoder and information holder.  A WebOb request is 
a whole framework, AFAICT.

That said, I expect zope.pipeline to give people a greater opportunity 
to prove I'm wrong about things like that.

> switch_pipeline -- could this be made non-Zope specific? It sounds useful.

I need to understand better what you mean by non-Zope specific.  How 
would you use it?

> log -- both repoze and paste have logging middleware, IIRC

Sure.  I haven't bothered to write this app at all since I know lots of 
people have written such things.

> open_root -- I thought repoze had something similar, but I may be wrong

I think this one is significantly different from Repoze.  It would be 
good to communicate about stuff like this at a sprint.

> clean_transaction -- is this not the same as repoze.tm2?

No.  To mimic the current Zope publisher, we need to commit the 
transaction shortly after the "call" application is finished, but then a 
lot of things can still happen before the response leaves the server, so 
we need to make sure any open transaction is aborted before letting the 
open_root application close the database.

This application is very small.  It might make sense to have the 
open_root application do its job instead.

> handle_error -- again, I thought Repoze had something like this

This error handling is very different from Repoze, I think.  It's going 
to handle errors the Zope way, by looking up error handlers in the 
database.  I imagine a lot of people will want to remove or customize it.

> end_transaction -- sounds like the other end of repoze.tm2

This is like repoze.tm2, but it will also annotate the transaction. 
Note that the code in my sandbox does not yet reflect this thinking.

> authenticate -- sounds like repoze.who?

I doubt it.  This does the IAuthentication dance, allowing 
authentication to be added during traversal.

> fix_relative_links -- sounds generally useful outside Zope as well

I wish, but this application depends on Zope's traversal logic to 
determine the canonical URL of an object.  I don't think the same 
traversal information will be present in most frameworks.

OTOH, I imagine fix_relative_links could be rewritten as a more broadly 
useful thing, if someone can figure out how without breaking performance.

Shane