[Grok-dev] grok 0.15 wishlist

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
> [snip]
>> The more I've been thinking about the Zope 3 publication machinery, the 
>> more I'm drawn towards repoze's much simpler approach. In particular, 
>> the usage of WSGI to assemble low-level machinery (e.g. transactions, 
>> logging, error handling, etc.) rather than the Component Architecture 
>> looks quite attractive to me.
> 
> Yes, this is definitely an area to watch. One debate is whether these 
> are "really" all proper WSGI middlewares or not, and whether that 
> matters..

Right. (I would say no to both points)

> If it works, we shouldn't care too much. We shouldn't go try 
> fit everything through WSGI, but we should definitely look into adopting 
> more of what's around.

Agreed.

>> So one straight-forward way to simplify the publication machinery 
>> already would be to base the replacement on what the repoze guys have 
>> created. They've also had their go at an object publisher (repoze.obob) 
>> but AFAIK that's just kept around for Zope 2 emulation. repoze.bfg is a 
>> nice and light-weight object publishing "framework", though anything we 
>> might create for Grok or Zope 3 as a whole would probably look a bit 
>> more complicated. I suppose it would also have to be backward-compatible.
> 
> Right, the Repoze guys don't have an object publisher that does what a 
> typical Zope 3 or Grok app would need. The repoze.obob + Zope 2 
> compatibility stuff is mostly geared towards Zope 2. The repoze.bfg 
> object publisher is just __getitem__ calls, and a bit too simple for our 
> purposes.
> 
> There are two kinds of backwards compatibility the "neo traverser" could 
> support:
> 
> a) URL compatibility - URLs under the old system work under the new 
> system in the same way.
> 
> b) pluggability compatibility - plugins written for the old system work 
> the same way under the new system.
> 
> Ignoring possible edge cases we may ignore, I'd like to get close to 
> full URL compatibility with the current Zope 3. In the interests of 
> simplifying things, I'm fine with ignoring pluggability compatibility 
> however, unless it turns out to be very easy to do in some cases.
> 
> What I'd like to see is a publisher/traverser somewhat closer to 
> repoze.bfg's traversal machinery in its simplicity (though still much 
> more complicated) and performance (though probably still significantly 
> slower).

Much agreed.