[Zope-dev] Zope.pipeline proposal

[Martin Aspeli]

Shane Hathaway wrote:
> 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.

You can configure multiple pipelines in a Paste Deploy file. It's up to 
the fronting web server to decide which 'pipeline app' to invoke.

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

The Paste#composite web app basically does this based on inbound 
subpath. It's not exactly hard to do in WSGI.

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

If this is the only reason to use the ZCA to register the pipeline, then 
maybe there's no need: only a fronting piece of middleware that picks 
the right pipeline.

Of course, there may be other things that make using the ZCA attractive.

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

I think it'd be a shame to produce a lot of new middleware that overlaps 
with the Repoze middleware, when both are born out of Zope. At least, we 
should try to re-use Repoze stuff wherever we can, rather than roll our own.

>> virtual_host -- is this the same as repoze.vhm?
> 
> Could be.  Not sure.

I suspect they are.

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

Ok.

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

Yes, kind of. I'm not sure using it would make sense for Zope. However, 
lots of other middleware does use WebOb requests, so it'd be useful to 
think about and document how they relate, if nothing else.

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

I'd imagine, to have multiple pipelines set up and have this middleware 
know which one to invoke. At the end of the day, to one piece of 
middleware, the 'pipeline' is merely one or possibly many callables that 
invoke the next piece of middleware/application.

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

Yes I think they'd be different, reading Tres' reply.

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

Why is it desirable to do things in this way? I do find it kind of 
confusing/error prone that we have two pieces of middleware: one that 
opens the transaction and another that closes it, with ordering 
dependencies between the two.

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

Sure.

>> authenticate -- sounds like repoze.who?
> 
> I doubt it.  This does the IAuthentication dance, allowing 
> authentication to be added during traversal.

repoze.who seems to be turning into something of a widely used standard. 
I think it'd be worth looking into whether it can be used 'upstream' and 
something else could do the IAuthentication stuff based on what 
repoze.who does. Not that I understand what the IAuthentication dance 
is. ;-)

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

Ok.

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

It may not be necessary, of course.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book