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 [EMAIL PROTECTED]
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 )
_______________________________________________
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 )
