On Mar 23, 2008, at 3:12 PM, Jim Fulton wrote:
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?
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?
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
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
repoze.kiss -- an obob plugin that implements filesystem serving of
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.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
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
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
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
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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -