[Zope-dev] Re: Exposing a the simple publisher (Re: Re: Reducing dependencies of zope.publisher)

[Tres Seaver]

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