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.
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?
retry -- is this the same as repoze.retry?
create_request -- should this maybe have some compatibility with WebOb
switch_pipeline -- could this be made non-Zope specific? It sounds useful.
log -- both repoze and paste have logging middleware, IIRC
open_root -- I thought repoze had something similar, but I may be wrong
clean_transaction -- is this not the same as repoze.tm2?
set_site -- sounds useful
event -- also sounds useful; I've had use cases other than setSite()
that require pre- and post-traversal event
handle_error -- again, I thought Repoze had something like this
end_transaction -- sounds like the other end of repoze.tm2
authenticate -- sounds like repoze.who?
fix_relative_links -- sounds generally useful outside Zope as well
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -