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.:

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.

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

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

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