[Grok-dev] grokproject + hurry.resource wsgi resource injection
trollfot at gmail.com
Sun Nov 14 13:15:20 EST 2010
It works as expected.
Another caveat : don't name your app "resources"
2010/11/14 Souheil CHELFOUH <trollfot at gmail.com>:
> Thank you for your amazing work, you and all the people involved.
> I'm going to test that, today
> 2010/11/14 Jan-Jaap Driessen <jdriessen at thehealthagency.com>:
>> 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
>> migration path.
>> 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:
>> - http://svn.zope.org/hurry.resource/branches/janjaapdriessen-resource-publisher/CHANGES.txt?rev=118402&view=markup
>> - http://svn.zope.org/hurry.zoperesource/branches/janjaapdriessen-wsgi/CHANGES.txt?rev=118375&view=markup
>> 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.
>> Some caveats:
>> 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
>> benchmarks 
>> Thank you in advance for your feedback,
>> Jan-Jaap Driessen
>> 1) http://www.peterbe.com/plog/using-md5-to-check-equality-between-files
>> Grok-dev mailing list
>> Grok-dev at zope.org
More information about the Grok-dev