[Grok-dev] grok 0.15 wishlist

[Martijn Faassen]

Hi there,

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

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

Regards,

Martijn



> Anyway, just my 2 cents.