With parallel handling (since it’s strongly recommended to make your service asynchronous, one could make a thumbnailer that handles in parallel), it’s of course up to the implementer of the thumbnailer to let the code make an intelligent decision about this.

With a simple LIFO queue where active requests can’t be canceled and where only one thumbnail is being generated at the time, you don’t have the problem (the second queued item will just notice the cached thumbnail, and will immediately return).

It could be useful for the thumbnailer to notice it in its queue (that another queued item is related to the current) and make the decision to instantly emit a `Ready` for both.

The specification allows this, it’s up to the implementer of a thumbnailer to build-in this kind of internal intelligence in his thumbnailer implementation.

Thanks for your suggestions.

I also assume that if there is one central service, that when other applications that also do thumbnailing, like the file manager, can detect duplicate requests – if only by noticing that there already is a thumbnail created when the queue comes to that point. Scenario for this: when copying files, both file manager and Tracker could react simultaneously. This could, in a worst case scenario with separate code, mean that both tries to thumbnail them all at the same time.

Very much awaited feature ! Hope that Nautilus, Gtk+, etc. will take advantage of this asap !

Regards,
Étienne.

It seems all indexers and backup systems could make use of FSevents userspace deamon, build on top of inotify and acessible via dbus?

Maybe someone could would build a sane backup system on top.

http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7
http://blog.rlove.org/2007/10/leopard-review-notes.html