That is exactly what i am recommending. :) If you guys start the discussion on relevant mailing-list (or irc) please let me know and I can try to help you push for this.

To avoid ambiguity, it only supports one cache backend at a time though. If an application requests a thumbnail, we can’t risk that it doesn’t know where to look for the final thumbnail after the request is finished. So we’re assuming that on each platform, one storage backend is used consistently. On deskop systems like GNOME and XFCE, this would be the XDG cache with PNGs in ~/.thumbnails/normal and ~/.thumbnails/large. All desktop apps look for thumbnails in those directories. On Maemo, thumbnails are stored as JPEGs and all Maemo apps look for those JPEGs instead of PNGs. Of course applications can be written to support both ways to load thumbnails.

So for the media server situation this would mean that it has to run in a dedicated environment (with the cache plugin using JPEG) where all applications agree that JPEG is good. Mixing this with desktop apps might get you into trouble though unless the thumbnail managing standard is extended to support JPEG alternatively.

If you have any ideas how to solve this in a better way, let me know. ;)

If you don’t know already, I am interested in this because of my DLNA MediaServer (http://live.gnome.org/Rygel) and DLNA explicitly requires thumbnails to be in JPEG format and not exceed the size of 160×160 so hildon-thumbnailer works better for me than current gnome applications. That is why I would really love to see the gnome thumbnail specs to be changed to comply with your standards.

One could also write a GObject class for calling the thumbnailer service. The level of control that applications need when requesting thumbnails varies strongly though. File managers need to do a lot of tuning (I did this in Thunar), while applications that only need a single thumbnail every once in a while could use the service in a much simpler way.

it ships with an in process library and a client-server using DBus. It supports generating fdo-compatible thumbnails but also more extensions, like borders/frames and even animated thumbnails, like those used in http://profusion.mobi/node/17

Of course it contains EFL-ism, like the animated thumbnail and frames, but maybe it’s worth considering. Also it’s a good comparison for generation speed, specially for large sets of png/jpeg using non-fdo. If you generate thumbnails from jpeg as jpeg it’s very fast.

FOSDEM sounds great, I was planning to attend anyway. ;)