[Grok-dev] grok 0.15 wishlist
Philipp von Weitershausen
philipp at weitershausen.de
Wed Sep 17 08:09:31 EDT 2008
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> 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
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.
>> 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
> There are two kinds of backwards compatibility the "neo traverser" could
> 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
More information about the Grok-dev