Proposed draft for the thumbnail D-Bus specification

Philip Van Hoof spam at
Fri Sep 5 02:55:01 PDT 2008

Hi there!

For everybody who's interested in this Thumbnail DBus specification:

"I am aware" that some people "just" want a thumbnailer that thumbnails
one file at the time.

For example like this:

jpeg-thumbnailer image.jpeg -s 128x128 -o \

"I am aware" that these people prefer that over having to implement a
DBus method like and writing all that
registration stuff that recently got re-specified in the draft[1]


For that reason I plan to implement a specialized thumbnailer that will
have a configuration file like this:




This specialized thumbnailer will simply register itself to the system
thumbnailer as a typical specialized thumbnailer. It will implement that
Create method by grouping if AcceptsMultipleFilesOnCmd and by calling
multiple spawns if not -> g_spawn_exec ($Exec, params, etc)

This will keep the current "feature" (at extreme values of the word
"feature" you can consider this to be a "feature", indeed) of most of
the current thumbnailers: "easy pluggability because you can just dump a
new executable somewhere".

Note on my personal opinion about this.

I don't agree it's a good architecture, because this architecture
doesn't scale with situations like: 

"I want the thumbnailer to schedule the creation of 800 thumbnails right
after my Photo application has copied 800 photos from my camera to this

Starting and stopping 800 thumbnailers with g_spawn_sync, and certainly
with g_spawn_async, introduces an immense amount of fork() and execv()
overhead. It voids any kind of libjpeg thumbnailing optimizations a
thumbnailer-writer could come up with.

But anyway ... 

Writing this (in the code of the prototype[2])


> It's somewhat untested and unfinished and at the same time tested (it's
> a prototype at this moment).
> I'm very interested in corrections, reviews, spelling fixes,
> concerns, ..
> Features of the draft:
> * Dependency on the Thumbnail-spec (this is definitely a feature, yes.
>   Let's start to agree on a common thumbnail storage once and for all
>   instead of all inventing our own incompatible thumbnail caches)
> * Queuing and indeed unqueuing requests. This makes it possible to let
>   the daemon forget about requests that got requested by accident (the
>   use-case being the window of a file manager closing before the
>   thumbnailing of items finished) (see lower for canceling)
> * Possibility for the daemon to send early results back for items that
>   it could finish sooner than other items. This is useful for already
>   cached thumbnails.
> * Possibility for third party vendors to provide a closed source, closed
>   or patented format thumbnailer by registering support for a MIME type
>   to a manager interface that is required to be implemented by the
>   thumbnailer service. Anti-patent feelings are irrelevant for this
>   this specification: I don't like patented formats too, but that averse
>   is irrelevant here - let's just make it possible and let us make
>   others decide for themselves, we are not the anti-patent police -
>   Generic thumbnailer: org.freedesktop.manager.Register
>   Specialized thumbnailers: org.freedesktop.Create
> * Possibility to queue a lot of items without having to send a lot of
>   DBus messages. Possibility for the daemon to reply `Ready` signals in
>   groups too (for the same reason).
> * Limited error reporting (I don't think file-managers are going to do a
>   lot with errors. But if necessary we can improve error reporting to be
>   topnotch)
> * Limited status reporting. You receive signals when a queued task is
>   started and when it's finished. You receive signals when individual
>   items are finished.
> * Intelligent thumbnail handling on Move, Delete and Copy. This allows a
>   file manager to inform the thumbnailer about Moves, Deletes and
>   Copies. Polling to keep the thumbnail cache correct is not implied by
>   this specification (and therefore not required, but permitted).
> Recommended by the specification
> * Asynchronous LIFO handling of the queue (strongly recommended)
> Not supported:
> * Canceling of activated requests. This is too hard to implement.
>   Functions like pthread_cancel are a no-option (leaks memory) and
>   starting and killing processes is not something I want to require by
>   the specification. The only viable option would be to adapt all
>   thumbnail algorithms to have meaningful cancel points. This is not
>   something I want to require from the specification.
>   I also looked at the current thumbnailing code of a few filemanagers.
>   Although Nautilus's private library has a load_image_cancel method, it
>   doesn't seem to be called (which makes me wonder why it was never
>   removed from nautilus-thumbnail.c)!
>   Nautilus's remove_from_queue and remove_all_from_queue are however
>   used by Nautilus itself. Therefore is this functionality available in
>   the D-Bus API.
> * Topnotch status reporting. This is too difficult for implementers of a
>   daemon to require in the specification. Just like canceling would it
>   require rewriting a lot of thumbnail algorithms.
> Notes
> Note that the not supported features don't mean that in future it wont
> ever be added to a 2.0 version of this specification or that in a custom
> DBus namespace a thumbnailer can't provide this functionality.
> -- 
> Philip Van Hoof, freelance software developer
> home: me at pvanhoof dot be 
> gnome: pvanhoof at gnome dot org 
> _______________________________________________
> xdg mailing list
> xdg at
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org

More information about the xdg mailing list