I didn't know about zope.publisher.paste, thank you. I've spent a little bit of time trying to grok zope.publisher.publish and the IPublication API, and indeed it seems there is almost a one- for-one mapping between Zope's "publication" and repoze.obob's "helper". It would almost certainly be possible to use a slimmed-down zope.publisher to do what repoze.obob/repoze.zope2 does now. But it would mean: - Implementing something Zope2-specific that implemented IPublication. - Implementing a new request type that handled traversal in a Zope2- ish way, that didn't support retry (as that's meant to be handled upstream). But essentially, if somebody was motivated, the code in Zope2ObobHelper at http://svn.repoze.org/repoze.zope2/trunk/repoze/zope2/z2bob.py could mostly be cut-n-pasted to allow the Z3 publisher to serve up a Zope 2 app. Two nits: - I don't like the fact that zope.publisher.publish uses the "setResult" API of the request to handle the result returned by the published object.. why wouldn't it just return the result? Maybe this dance was cargo-culted over from Zope2. - I don't like that the request handles traversal. This also smells like it was cargo-culted from Z2. Why shouldn't the publication itself do traversal? Traversal is extremely policy-laden, why break the code that implements that policy up so that you need "matching" request and publication objects? - C On Mar 25, 2008, at 3:50 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote:
Jim Fulton wrote: [snip]
Thoughts? Objections? A simpler publisher has been on my wish-list for a long time now.
I'm a bit worried though that a publisher born from the current Zope 3 publisher with the goal to build up enough support for the Zope 3 publisher to make use of the code will not in fact be simpler. The current Zope 3 publisher supports quite a few pluggability points (though not necessarily always in the most convenient places), and has a lot of interacting components, which makes it rather hard to comprehend sometimes.
I suspect you are confusing, as the repoze folks seem to have, the publisher, with the way that the Zope 3 server set up code wires it up.
I spent a couple of days trying to work out how those bits were interacting, back before we re-implemented a bobo-like thing as 'repoze.obob'. Its intro doc lays out our goals:
- ------------------------------------------- repoze.obob Overview
This package provides a paste-configurable version of the classic 'bobo' publisher, which maps request URLs to objects via graph traversal. It is desgined to be the endpoint ("application") in a WSGI filter / application pipeline.
The publisher is responsible for:
- converting the WSGI environment into a request object and its corresponding resopnse object;
- selecting the "root" object of the graph for a given request / URL;
- traversing from that root object along the "edges" defined by the URL path elements to find the "published object";
- invoking the published object, mapping any request parameters onto its arguments;
- mapping response headers and body, along with the result from calling the published object, into appropriate WSGI output.
The publisher is *not* responsible for the following tasks, which belong to WSGI "middleware" components:
- setting up any transaction;
- committing or aborting a transaction;
- retrying failed / conflicting requests;
- converting Python exceptions into HTTP response codes.
- ----------------------------------------
In particular, we wanted to move all those excluded responsibilities out into middleware, so that they could be shared across multiple WSGI applications, including those which were not Zope-specific at all. We've been successfull at that goal: the Pylons and TurbooGears folks are working on integrating repoze.tm into their stacks, for instance.
repoze.obob puts all the policy for publishing into a set of plugins passed in at construction (typically configured via Paste configuration):
- Initializing anything at startup
- Finding the root object
- Handling the policy-driven bits of the publishing traversal, calling the published object, and converting the result. This part is largely like what the publication object does, except the "find the root object" bits, which we broke out.
We have a re-implementation of the classic Zope2 publisher machinery (repoze.zope2.z2bob) which suppy these policy implementations. repoze.kiss, for instance, works by just replacing the "root finder" part with version which creates a proxy object for a filesystem directory: the "Zope2ObobHelper" then works fine against that alternate root.
When we originally set up zope.server at the dawn of Zope 3, we inadvertently created a gordian knot of interacting components. When we added WSGI and Twisted support, we just made this worse by adding additional threads.
The publication factory dance is completely inscrutable.
The basic publisher framework is pretty straightforward. There is a generic publisher and a publication component that takes care of customizing the publisher for a particular application. The publication interface, zope.publisher.interfaces.IPublication, defines the available hooks. The recent addition of zope.publisher.paste makes selection of a custom publisher much simpler -- as well as supplying paste support. Unfortunately, I don't think anyone has paid attention to this. :(
I haven't looked much into it. I would be happy to have a simpler way to set up the Zope3 publisher, free of the policy stuff embedded in the existing publication objects.
If all you want is more control over how the publisher works, I think the current publisher simplified via the new paste support should meet your needs. It's possible some folks need more hooks, but then we should focus on evolving the publication API, zope.publisher.interfaces.IPublication.
Can we implement a publication which defers error handling / transaction handling / retry handling to middleware? The 'repoze.grok' package, for instance, works around the error handling bit by adding a WSIG "ingress" filter which stuffs a key into the WSGI environment ('wsgi.handleErrors') to get the Zope3 WSGI application to defer error handling.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH6Vd2+gerLs4ltQ4RAlX9AJ94LIc9s125p6cGsitBXDoN6g0bfwCff7uZ B8ztzcxpF4hw+qBHXxtxZeE= =AASc -----END PGP SIGNATURE-----
_______________________________________________ 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 )