[Grok-dev] grokproject + hurry.resource wsgi resource injection

[Jan-Jaap Driessen]

On 14 November 2010 16:20, Jan-Jaap Driessen
<jdriessen at thehealthagency.com> wrote:
> Hi,
>
> 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
> hurry.zoperesource:
>
> svn.zope.org/repos/main/grokproject/branches/janjaapdriessen-hurry.resource
>
> (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
> much of a designer, I just needed some css and javascript to see that
> 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
> URLs?
>
> 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
> this?
>
> * 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 [1]
>
>
> Thank you in advance for your feedback,
>
> --
> Jan-Jaap Driessen
>
> 1) http://www.peterbe.com/plog/using-md5-to-check-equality-between-files
>

Hi,

An updated version of grokproject + fanstatic is available on my branch:

http://svn.zope.org/repos/main/grokproject/branches/janjaapdriessen-hurry.resource

Some observations:

0. hurry.resource and hurry.zoperesource have been renamed to
fanstatic and zope.fanstatic. They live on bitbucket now:

http://bitbucket.org/fanstatic/

1. A feature branch of grokui.base is pulled in to make grokui.admin work.

2. A feature branch of grokcore.view is used to make 'static' work: I
have dropped the static grokker from grokcore.view, in lieu of
registering a fanstatic library under the name of the
package/application. This means 'static' still works as you expect it
to, as you can see in the page template in the result of a grokproject
run. The only difference is that the files in the 'static' directory
are served by the fanstatic publisher.

3. I duplicated the zope.conf into debug and deploy versions. These
are referenced from the paster configuration file. If you start your
application with debug.ini, both fanstatic and grok are started in
debug mode. This means that page templates are re-evaluated after you
change them, and URLs to resources are re-calculated for every
request.

If you start the application with deploy.ini, both fanstatic and grok
are started in deploy mode. Page templates are read only once,
resource URL calculations will be cached. The resources are injected
into the page using minification, rollup and bottom-including
techniques (only if rollupped and/or minified versions are available
for your resources that is).

4. You cannot use the '++resource++foo/icon.png' notation in CSS any
more. Use relative paths instead. I wonder if these kind of URLs were
ever supposed to be used in this way.

And one question:

What is the future of grok and fanstatic? Will fanstatic be an
integral part of a grok application for serving resources? In that
case, we can remove the DirectoryResource code from grokcore.view. We
can remove the code in grok that handles resources, such as
DirectoryResource in grokcore.view.


I would like to hear your opinion.


-- JJ