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

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 + 
some cleanups.

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

Reply via email to