Image Cache

[andre@…]

Hello,

your macro is a really goot idea. I have scripted a new version with an image cache. So the yuml images are loaded faster from the local cache instead from yuml.me.

The cache is the directory "cache/yuml/" in "<yourtracpath>/htdocs". Trac need the permissions to write in this directories. There is also a cache table in the database (yumlcache), that remermbers which yuml content belongs to which image id. Thus, after installing the plugin you must upgrade your trac environment (type in your shell: trac-admin <yourtracpath> upgrade).

If there is an error in your yuml content, yuml.me won't give you an image. In this case the plugin shows an error-image.

I have tested the plugin with trac 0.11 and python 2.4. I hope you enjoy this enhancement and all works fine for you (it is my first python script).

CU André

[andre@…]

The source code of the enhanced plugin.

[Daren Thomas]

André, thank you very much! I will review your changes and add them to the repository asap!

[Daren Thomas]

André, I've just read your code. Wow. Not bad for your first python script! Before I add this code, I'd like to discuss some things with you:

• I'm pretty new to the plugin concept (this was my first trac hack...) and wonder why you chose it over the simple single file macro.
  • I'm guessing it is to get a chance to upgrade the database and add a table there
• I propose we don't bother with a separate database table and use a hash of the content variable to find the cached image. That way we could leave the macro as a single file
  • would switching to the plugin api buy us anything? easier install?
• Actually, your browser already does image caching. So would a proxy.
• I love the idea of an error message. We definitely need to add that!

This is how I envision using hashes to find the images: We create an md5 hash of the content variable and store that in htdocs/images, possibly prefixed with 'YumlPreprocessorPlugin'. This way, we can always check for a cached image without looking it up in a database. Of course, after a while, the cache will begin to grow.

I checked the headers of the image returned from yuml.me:

$ curl --head "http://yuml.me/diagram/scruffy/class/%5bMyTest%5d"
HTTP/1.1 200 OK
Date: Thu, 23 Sep 2010 07:25:12 GMT
Server: Apache/2.2.3 (Debian) Phusion_Passenger/2.0.2
X-Runtime: 2931
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.0.2
Content-Transfer-Encoding: binary
Cache-Control: private
Content-Disposition: inline; filename="67329bf3.png"
Content-Length: 3388
Vary: Accept-Encoding
Content-Type: image/png

It looks like they don't specify any expiry dates for the images they return. This would thwart any image caching by browser / proxy / ISP, which is a bad thing. I'm going to write to yuml.me and ask them to add this information in their headers - that would make local caching unnecessary...

[anonymous]

Hi,

thanks for your answer. You are right, I had to give up the single file macro to got a chance to setup the cache table on the database. There is a small ​tutorial to learn the basics of this plugin concept.

Anyway, if we have a chance to get rid of the cache table, the trac admin won't have to upgrade the trac environment. So, we should try to realize it without a cache table in the database. Your md5 idea is very good, I hope the possibility, that two different contents lead to the same hash is very very small.

I think a local cache on the trac-host is the best solution, because you are not dependent on a third party service. After writing the content into a wiki page, the trac host tries to get the diagram-image and if this image is stored to the local cache, the diagram belongs forever to this trac-wiki, even if yuml.me must give up its service.

Feel free to get in touch with me, if you need any assistance in rewriting the macro.

Bye, André

[anonymous]

I wrote to yuml.me on 9/23/2010, notifying them of the Cache-Control: private header, it seems they have changed this since:

$ curl --head "http://yuml.me/diagram/scruffy/class/%5bMyTest%5d"
HTTP/1.1 200 OK
Date: Mon, 03 Jan 2011 16:55:35 GMT
Server: Apache/2.2.3 (Debian) Phusion_Passenger/2.0.2
X-Runtime: 2
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.0.2
Content-Transfer-Encoding: binary
Content-Disposition: inline; filename="67329bf3.png"
Cache-Control: public, max-age=31000
Content-Length: 3388
Vary: Accept-Encoding
Content-Type: image/png

I do not have the resources to implement this caching feature. If you would like to add it, please feel free to do so. I might have to grant you access to the system and you can become owner if you like, andré.

Also, please accept my apologies for not acting sooner on this issue. I kept you on my low priority list and hope you don't take that personally. If you are still interested in this feature, I am willing to spend some time to get you up and running. Thank you for your help!