Re: Specifying thumbnailers as a service

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2008-09-01 at 10:25 +0200, Lubos Lunak wrote:
> On Friday 29 of August 2008, Philip Van Hoof wrote:

>  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

I have not seen many other thumbnailers have progress or status
information. You could do per-item progress information by calling it
file per file.

I could add a signal like:

<signal name="Progress">
     <arg type="s" name="level" /> <!-- Either "item" or "group" //-->
     <arg type="i" name="percentage" />
</signal>

I'm not sure if this ain't making the specification too complex for
implementers for a thumbnailer.

I think canceling is overkill. Making a thumbnail doesn't take longer
than a minute (and a minute is an extreme case). Users don't cancel
that.

> - 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.

Which thumbnail-sizes to generate is a configuration / implementation
detail of the thumbnailer. On a tablet PC, for example, I guess that
only the small size might be sufficient.

We could do something like this of course:

<method name="Create">
   <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>
   <arg type="as" name="uris" direction="in" />
   <arg type="s" name="kind" direction="in" /> <!-- Either small, normal or both //-->
</method>

I wonder what other people's opinion is about this?

> - thumbnail generators usually don't go via saving to disk but use some more 
> efficient way (e.g. pass data in-process)

Passing pixbuf data over IPC doesn't sound very efficient to me. I also
wonder why you would do that over IPC?!

Just make a library that does it for your application (like your
`create_image` below).

Your service is in your use-case not doing anything that you would
expect from a service. So why make it a service then?

However.

For some files (and file-types) will the generation of a thumbnail take
a lot of time, so when most applications request a thumbnail, they mean:

	"create me the thumbnailcache for this file and callback"

when they request the creation of the thumbnail.

For the purpose of specifying the storage of that cache, we already have

	http://jens.triq.net/thumbnail-spec/index.html

This proposal is about specifying requesting the creation of a thumbnail
in that cache.
   ^^^^
You can of course still make a library that just creates the thumbnail.

But that's only related in so far that this library could consume that
service (if the library is configured to do so).

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

This specification is not intended to be a replacement for a library
that gives you thumbnails in a specific pixbuf format. It's intended to
ask for a request for the creation of a thumbnail in a thumbnail-spec
formatted cache (and to reply when finished).

A possible consumer of that service would be the library that implements
a function like create_thumbnail.

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

That's not related to the specification being proposed, but related to a
library for passing the thumbnail in the form of a pixbuf to the
application developer.


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