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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
