Proposed draft for the thumbnail D-Bus specification

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 \
	 $HOME/.thumbnail/small/md5ofimage.jpeg

"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[1]

[1] http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052

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

$XDG_CONFIG_HOME/.exec-thumbnailer/config

[image/png]
Exec=/usr/libexec/exec-thumbnailer/png-thumbnailer
AcceptsMultipleFilesOnCmd=true

[image/jpeg]
Exec=/usr/libexec/exec-thumbnailer/jpeg-thumbnailer
AcceptsMultipleFilesOnCmd=false

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
directory"

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])

[2] https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/daemon/

> 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 
> http://pvanhoof.be/blog
> http://codeminded.be
> 
> 
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be