[Zope-dev] Re: Reducing dependencies of zope.publisher

[Chris McDonough]

On Mar 23, 2008, at 3:12 PM, Jim Fulton wrote:
>>>>> No-more so than the existing publisher.  I just want to make  
>>>>> the   publisher useful for small applications that don't need  
>>>>> the  component  architecture and other facilities that  
>>>>> zope.publisher  depends on for  mostly minor reasons.
>>>> This is of course a good goal in itself, though I'm curious how  
>>>> it  compares to the Repoze publisher and its "obob" machinery?
>>> Me too.  I have a hard time figuring out what repoze is and I  
>>> don't  necessarily want to go swimming to find out. :) Is the  
>>> repose  publisher described somewhere?

The (relatively) nontechnical overview is at http://repoze.org/about.html

The "repoze.obob" "publisher" (it's actually more of a meta-publisher)  
is described here: http://svn.repoze.org/repoze.obob/trunk/doc/ 
intro.txt ... it's mostly a "traffic cop" which delegates most of the  
hard work to plugins.  repoze.zope2's "Zope2ObobHelper" (in http://svn.repoze.org/repoze.zope2/trunk/repoze/zope2/z2bob.py) 
  is one such helper.

More generally, Repoze is a brand that mainly implies "WSGI components  
inspired by Zope, which can be used outside of Zope". The individual  
components (see http://svn.repoze.org) are quite small and can be  
installed and used independently from each other, e.g.:

Middleware
----------
repoze.tm -- WSGI middleware that uses the Zope transaction machinery  
to supply a transaction policy in a WSGI pipeline
repoze.errorlog -- WSGI middleware that serves a purpose similar to  
that of the Zope 2 "error_log" object.
repoze.who -- WSGI middleware that serves a purpose similar to that of  
Zope 2's PAS.
repoze.profile -- WSGI middleware that can be used to profile  
applications.
repoze.retry -- WSGI middleware that can retry a request based on a  
configurable policy (eg. a ConflictError)
repoze.browserid -- WSGI middleware that serves a purpose similar to  
that of Zope 2's "browser_id_manager".
repoze.decsec -- WSGI middleware that serves as a framework for  
defining and enforcing a declarative security policy.
repoze.vhm -- WSGI middleware that serves a purpose similar to that of  
Zope 2's virtual host monster.

None of these middleware components depend on each other and none of  
the configuration of any component depends on exposing the component  
architecture in any form to the end-user.

Applications
------------
repoze.obob -- a WSGI application that implements a bobo-like publisher
repoze.zope2 -- an obob plugin that implements Zope 2 publisher  
semantics
repoze.kiss -- an obob plugin that implements filesystem serving of  
content
repoze.grok  -- an application which allows easy serving of Grok from  
a paste pipeline.
repoze.plone -- a package which includes plone and which depends on  
repoze.zope2
repoze.django -- a WSGI application that allows you to run Django  
under a Paste pipeline
repoze.trac -- a WSGI application that allows you to run Trac under a  
Paste pipeline

Misc
----
repoze.recipe.egg -- a zc.buildout recipe which does the same thing as  
zc.recipe.egg but installs dependent scripts

One point of all this stuff is mostly to be able to use Zope-like  
technologies in unfamilar environments (like Django, Pylons, etc) and  
carry knowledge across these platforms as necessary during consulting  
jobs.  Relieving Zope of some of its duties (like error handling)  
allows us to trivially use middleware produced by people who aren't  
Zope people that is better suited for the task.

>>> I would like to create a 21st-century Bobo and this minimal  
>>> publisher  is part of that plan.  If I create a new Bobo, I want  
>>> it's  requirements to be minimal.  I don't want to depend on  
>>> something as  big as repoze seems to be.

repoze.obob's setup.py says it depends on PasteScript and WSGIUtils.   
This is unfortunately a lie.  It depends on only the stdlib.

>>>
>>
>> I think Repoze is a collection of many very small parts, rather  
>> than a very big whole. To me (i.e. to Plone), it's a way to deploy  
>> Zope 2 applications (Plone) in a WSGI way with pipelines and  
>> filters and all the rest of it. Repoze is also splitting out some  
>> of the useful bits of a monolithic Zope into re-usable middleware,  
>> including virtual hosting, transaction co-ordination, retry, and  
>> profiling.
>
> OK, I get that from the repoze about page. That doesn't explain why  
> it should be relevant to my proposal to create a stripped-down Zope  
> 3 publisher.

It isn't, except that you *might* want to consider making the new z3  
publisher a repoze.obob plugin.  Or not.  The basics are there, but  
it's not very compelling unless you want to let folks change  
publishing semantics arbitrarily by supplying alternate plugin  
implementations.

>> I suspect that the reason the Repoze guys ended up rewriting the  
>> Zope 2 publisher is that it was too monolithic to support  
>> deployment as a WSGI application.
>
> Well, that's not my problem, on 2 counts. 1) I'm not using the Zope2  
> publisher. :) 2) The Zope3 publisher works just fine with WSGI and  
> Paste. I suppose Tres and Chris didn't reuse the Zope 3 publisher  
> for this because .... actually, I have no idea why they didn't.  I'm  
> pretty sure the Zope 3 publisher has the necessary hooks to allow  
> someone to implement Zope 2 publisher semantics.

I'm pretty sure that no one actually knew the Zope 2 publisher  
semantics until we reimplemented the Z2 publisher.  The semantics are  
unreasonable.   But at this point, given that we've now reimplemented  
it, and we understand them, it might be possible to use the Z3  
publisher to emulate them.  It'd be hard to tell without actually  
doing it and there are no plans to do so at the moment, though.

For repoze.grok we did indeed just use the current WSGI app support in  
zope.app.wsgi, so repoze.grok is much simpler than repoze.zope2.

Some observations we had while dealing with the current Z3 publisher:   
although the current Z3 publisher has a lot of policy knobs, they seem  
to be in the wrong places.  For example, IIRC, in repoze.grok we had a  
lot of difficulty trying to figure out how to make the publisher *not*  
catch errors (we want to let WSGI middleware handle errors).  We did  
eventually figure that out ("we" meaning Tres anyway), but we never  
did figure how to prevent the publisher from handling its own  
transaction management, nor did we figure out how to publish a  
different root object than the ZODB root, nor did we figure out how to  
prevent the publisher from doing its own conflict retry management.   
I'm sure all of these things are possible, but it's currently a bit  
complicated.

Additionally, because zope.publisher currently depends on other pieces  
of Zope3 which themselves have dependencies, and so on, it's  
effectively pretty big (~18 eggs currently).  This was not optimal.

I'm a strong +1 on a simpler, smaller Z3 publisher.  The only  
relationship this *might* have to Repoze is that we'd like the  
publisher to do a lot less, so we can handle some of its current  
duties (e.g. transaction management, error handling, retry) in  
middleware.  Optimally without making the middleware depend on the  
component architecture to do so.

Of course, we'd (or at least I'd) be willing to help in the effort.

- C