Re: [Tracker] Specifying thumbnailers as a service

[Lubos Lunak <l lunak suse cz>]

On Friday 29 of August 2008, Philip Van Hoof wrote:
> Hi there,
>
> Not only filemanagers want to request the creation of a thumbnail. For
> example desktop search engines like Strigi and Tracker want to schedule
> the creation of thumbnails for certain of the contents that they find,
> ahead of time (not sure about Strigi, as one of Tracker's developers
> myself I'm sure about Tracker).
>
> This is why we would like to have a desktop wide DBus API for requesting
> the creation of a thumbnail. Not just a specification about how to store
> the thumbnails and where you can find them [1], but also a method to
> request thumbnails.
>
> We want to reuse the infrastructure that is available.
>
> We want to request the creation of a thumbnail for rather a lot of items
> so this API would have to accept a an array of paths to thumbnail-able
> items. When finished it would return an array of paths to the
> thumbnails.

 Is this API also intended to be used by filemanagers? It appears to have 
several performance problems for use in those:

- there is no notification about progress (i.e. when a thumbnail is done), so 
a filemanager showing a directory would have to wait for all thumbnails 
created there (unless it wants to watch the thumbnail directories for a 
change). Also, even if there was such a signal, it would probably be nice to 
also have a request for cancelling the create request, in order to change 
what should be generated when the user scrolls around in a view with many 
files
- not in your original proposal, but in the thread it is said that the create 
request should not request a specific size, instead the thumbnailer should 
handle sizes normally according to the thumbnailing spec. This would make the 
generation take longer and presumably waste space with unused sizes.
- thumbnail generators usually don't go via saving to disk but use some more 
efficient way (e.g. pass data in-process)
- also, it is not really necessary to actually keep thumbnails on the disk, I 
use my image browser with the disk cache turned off, as that's generally 
faster that way. The API however cannot work this way.

 Since all applications using this API need to be handle the thumbnail spec 
anyway, wouldn't it be better to have the API like

image create_thumbnail( string file, int size )

? Plus some simple way how to find which .so to load for this entry hook?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz