Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Wed Sep 3 07:15:20 PDT 2008
Hi there whoever is interested in thumbnailing!
This is the location to the draft:
This is the Subversion repository to a prototype implementation:
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,
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
* 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
* 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)
* 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.
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
More information about the xdg