Hanno Schlichting wrote:
> On Sun, Jan 17, 2010 at 10:51 AM, Wichert Akkerman<wich...@wiggy.net> wrote:
>> There is something to consider: I suspect more things are started to
>> require the new publisher events from Zope2, either directly or via one
>> of the backport packages for Zope 2.10. I'm not sure if repoze.zope2
>> supports those.
> A "fork" clearly comes with a cost here. I think neither the publisher
> events nor the exception view changes of Zope 2.12 have made their way
> into repoze.zope2. It's not all that hard to do, but without someone
> driving the project forward, we have diverging code bases and
> something like Plone 4.0a3 probably doesn't run on repoze.zope2 right
Exception view changes did, I think.
Publisher events didn't.
Anyway, I think the next "big" thing for Zope 2 is to merge this back
into the WSGI publisher, which Tres did some fixing up on recently as
well. I'd be willing to help with that, since I have a fair amount of
experience with repoze.zope2. I'm hoping to drag Hanno down that
particular gutter too. :)
My dream would be a Zope 2.13 that would be an unsupported-but-working
configuration for Plone 4 (probably via an extended KGS with some
additional packages not part of the core 2.13 KGS but required for 2.12
compatibility), with a WSGI publisher by default based on repoze.zope2 +
I think this is feasible, especially if we say that we are only going to
support a defined API for the publisher, and drop some of the
implicit-and-weird stuff that the current ZPublisher does. That means
that if you want 100% compatibility, you work with ZPublisher; if you
want 80% compatibility and WSGI, you use the new publisher. The
advantage is that repoze.zope2 has decent internal documentation and
tests and is a lot easier to understand than ZPublisher.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Repoze-dev mailing list