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:
Hash: SHA1

Jim Fulton wrote:
On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote:

Jim Fulton wrote:
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

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
 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 /

   - 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

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,

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

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope )

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to