caching issues with /globals

Deferring this.

The new filesystem site does allow one to associate these. It's not done
automatically however yet upon installation. Moving this to Silva-future.

review this for Silva 1.1

Moving to 1.2.

review this for 2.1, whether it is feasible?

Agreed.

It is possible to automatically configure FSObjects to use a predefined cache manager.

I created an accelerated http cache manager, service_static_cache_manager. (also caching non-anonymous requests) I took an image in globals, 'ranking.gif', and added a metadata file 'ranking.gif.metadata'. In this file, I placed the following:
[default]
_Cacheable__enabled=1
_Cacheable__manager_id=service_static_cache_manager

I restarted zope, shift+refreshed the image in Firefox with livehttpheaders active. The accelerator was called when the object was rendered, so this procedure will work.

The only slight-negative is that all files will need a .metadata file associated with them, which contains the content from above. So, think hard now about what you want this http accelerator to be called!

This approach could also be taken for various SilvaViews filesystem assets.

There's no documentation anywhere about these .metadata files, so wrote one up, here:
http://altepeter.net/tech/articles/fssite_metadata

Please advise on how you'd like to proceed here. I'll be happy to add .metadata files for these, and look into adding for static css, js, and image assets in the views as well.

This should greatly improve cacheability...for now (at Bethel), since we run Silva behind Apache, I've been using Apache to set the cache headers.

Kit has given the go-ahead, so I'll be putting this in the silva trunk.

Committed this into the Silva trunk. Someone (probably me) should go through the Silva views and associate static files with this cache manager as well. I'll create an additional issue to track this.

Note also, that I think using a (different) cache manager like this for Silva Files and Images should address this "high priority" issue as well: https://bugs.edge.launchpad.net/silva/+bug/100620

I've done some minor testing and everything seems to be working well. This is a great improvement in Silva performance.

I notice one thing from watching the cache manager statistics at /[mySilva]/service_static_cache_manager/manage_stats, the /[mySilva]/service_views/Silva/edit/VersionedContent/kupustyles.css seems to get hit every time you go to a document for the first time. Not a huge problem, but I wonder why because it does have a metadata file. Actually after playing with this for a while, I bet I know why: it's being acquired and so the path is different. The same thing happens if one goes to /globals/globals/up.gif

Do you think the title of the service is appropriate?
"Cache Manager for static non-silva objects"
or
 "Cache Manager for static file-system objects"?

Note: this is similar to a problem we had (and solved) with resources in SilvaLayout, where I think we went around acquisition, and have a something like 'get_resource_path' or something, which returns a static url for all the resources such as css, js and images. Not sure if it makes sense/is even possible to use that here too.

In SilvaDocuments tab_edit, I changed the kupustyles.css to be an absolute url pointing to the real location within service_views. I also did this with the tab_edit of SilvaNews, and added metadata files for SilvaNews assets.

Also, I changed the title of the service in install.py as per Kit's suggestion.