Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Fri Sep 5 02:55:01 PDT 2008
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 com.company.Thumbnailer.Create() and writing all that
registration stuff that recently got re-specified in the draft
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)
> 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
> * 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.
> 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 lists.freedesktop.org
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
More information about the xdg