[Zope-dev] Re: Exposing a the simple publisher (Re: Re: Reducing
dependencies of zope.publisher)
Chris McDonough
chrism at plope.com
Tue Mar 25 16:41:43 EDT 2008
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 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-----
>
> _______________________________________________
> Zope-Dev maillist - Zope-Dev at 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 )
>
More information about the Zope-Dev
mailing list