[Grok-dev] grok 0.15 wishlist

[Philipp von Weitershausen]

Martijn Faassen wrote:
> * WSGI/Paste support out of the box with dev/deployment profiles, this 
> time for real. Volunteers to drive this, please!

I won't try to disappoint again by signing up for this, but I'll mention 
a few points about this:

For the short term, it would be fine to adopt the strategy of 
zopeproject's code which uses zope.app.wsgi.getApplication(). This 
wouldn't really change the way the application is started and the 
publication machinery is initialized, except that our application isn't 
generating zopectl scripts anymore, it just provides an application 
factory entry point for PasteDeploy.

For the long term, I think we want to do something about the publication 
machinery. It's interesting to hear that Martijn is thinking in this 
direction as well:

> * At the tail end of the DZUG meeting last week I started a "way out 
> there" project to replace the rather hard to understand 
> publishing/traversing machinery of Zope 3/Grok (spread through many Zope 
> 3 packages) with a single-package version. This might hopefully make 
> things more understandable and hackable. This is of course extremely 
> experimental, and risks breaking backwards compatibility (definitely 
> will in some ways, in fact). But one day we'll have a Grok 2.0 after 
> all! I think it's time we started reconsidering some core components of 
> Zope 3 and seeing whether we can't simplify things a bit given the 
> lessons we learned. We want to make the distance between the WSGI app 
> layer and Grok as small as we can make it.

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.

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.

Anyway, just my 2 cents.