[Grok-dev] grokproject + hurry.resource wsgi resource injection
jdriessen at thehealthagency.com
Sun Nov 14 10:20:08 EST 2010
At the Zope summit Jan-Wijbrand and Martijn cooked up ideas for
offloading the serving of resources from grok/zope to WSGI middleware.
During the sprint Christian Klinger and I worked on an implementation
of these ideas, based on work Martijn had already done in the most
recent versions of hurry.resource, hurry.zoperesource and serf. The
goal is to offload serving of resources to a WSGI component in order
not to make `expensive` calls to the zope publisher. It would be nice
if we could have backwards compatibility and some kind of easy
I invite you to have a look at the following branch of grokproject,
which integrates the feature branches of hurry.resource and
(If you don't have svn access to svn.zope.org, change the [sources]
information in the resulting buildout.cfg from svn+ssh:// to http://)
The changes are documented here:
As you fire up the newly created instance, you will notice I am not
the resource handling is actually working.
Turning the hurry.resource.publisher off is easy: remove the
publisher_prefix in the resource_injection part of parts/etc/debug.ini
and the resources will be served by zope.
1. Don't name your project 'foo', as this resource name is used in the project.
These issues are still on my todo list:
1. Creating URLs to resources from page templates. As you can see in
the result of the grokproject run, the img generated by the page
template is still served by zope.
2. ease of configuration: We should be able to turn caching/hashing on
and off in the paster configuration. This depends on whether the
application is running in dev mode or not.
3. tests + documentation
4. Make this functionality available in non-zope WSGI applications.
5. Deployment: Does this setup play nice with Apache + mod_rewrite or
mod_wsgi? What about virtual hosting and ++skin++ information in the
6. The publisher should not serve '.svn/entries' files and the like.
7. Recalculate content-length header after modifying the body of the
request in the injection middleware.
And we may want to answer the following questions:
* What is the future of 'static' in grok?
* Should we make the wsgi injection middleware and the publisher into
one component instead of two, for ease of configuration?
* The hurry.resource.core._plugin is global. This means we can not run
multiple plugins in one runtime. Can we find another way of doing
* hash md5 vs zlib for computing hashes: Do you have any thoughts on
this? I used zlib.adler32 because it is fasted in Peter Bengtsson's
Thank you in advance for your feedback,
More information about the Grok-dev