[Grok-dev] grok 0.15 wishlist
Philipp von Weitershausen
philipp at weitershausen.de
Wed Sep 17 03:07:50 EDT 2008
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.
More information about the Grok-dev
mailing list