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
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
> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -