People who know me probably saw this blog item coming. Here it is!
In Tracker we want to ahead of time create thumbnails for interesting files. Among the use cases
is when the user has moved or copied photos from his camera into one of the photo folders. We
want to start preparing thumbnails for those files early so that filemanagers and photo
applications are fast when needed.
The current infrastructure for this in Tracker is to launch a script for each file that is to be
thumbnailed. If you find a lot such files (some people end up with a camera with 1,000ths of
photos after a busy weekend), that would mean that we’d do this 1,000 times:
fork(); execv(tracker-thumbnailer); fork(); execv(bash); fork(); execv(convert);
Luckily this is not activated by default in current Tracker. :-)
I don’t have to explain most people who read this blog that this is a bad idea on a modest
ARM device with a bit more than one hundred MB of RAM. A better idea would be to have a service
that queues these requests and that solves the requests with specialized image libraries. Perhaps
launching a separate binary for the MIME types that the service has no libraries for?
At first we were planning to make tracker-thumbnailer listen on stdin in a loop. Then I
figured: why not do this over DBus instead? Pretty soon after that was Ivan Frade
concluding that if we’d do that, other applications on the device could be interested in
consuming that service too. We decided that perhaps we should talk with the right people in the
two large desktop communities about
the idea of specifying a DBus specification for remotely managing the thumbnail cache as
specified by the Thumbnail managing standard by
Jens Finke and Olivier Sessink.
I don’t know of a official procedure other than filing a bug on freedesktop.org, so at
first I tried to get in touch with people like David Faure (KDE), Christian Kellner (Nautilus),
Rob Taylor (DBus, Telepathy, Wizbit) and later also a few mass discussions on #kde-devel,
#nautilus and #gnome-hackers.
I started a
discussion on xdg-list which made me conclude that such a DBus API would indeed make sense
for a lot of people. Discussions with individuals on IRC added to that feeling. I started
a draft of a first specification for a DBus
API.
Meanwhile I had already started adapting
the hildon-thumbnail code to become more service-like. Right now that code has a DBus daemon
that implements the draft DBus API and on top
of that provides the possibility to have dynamically loadable plugins. The specification also
allows registering thumbnailers per MIME type. For that reason I made it possible to run those
dynamically loadable plugins both
standalone and in-process of the
generic thumbnailer.
It has been my prototype for testing the DBus API specification that I was writing. People told
me that if you want to make a specification that’ll get accepted, the best way is to write
a prototype too. Meanwhile Rob Taylor had joined me on fine tuning the specification itself. With
his DBus experience he helped me a lot in multiple areas. Thanks for caring, Rob!
The current prototype does not yet make it possible to simply drop-in a thumbnailer binary to add
support for a new MIME type. By making a standalone thumbnailer that for being a thumbnailer
simply launches external thumbnailers you could of course add that possibility that a lot of
current thumbnail-infrastructure has. Although as mentioned above I don’t think this is a
good architecture (the fork() + execv() troubles), I plan to make such a standalone plug-in
thumbnailer.
I certainly hope that this specification will be approved by the community. I can help with
making patches for Konqueror and Nautilus. We’ll most likely use this on the Maemo platform
for thumbnailing ourselves.
0
0
Les Cleveland Cavaliers ont
annoncé samedi le rachat des droits du jeune ailier Darnell Jackson (Miami) en
échange d’un second tour de draft en 2009.
Category: Sports
Recommandations
)
and reject those that you are not interested in
(
)
