Review of the thumbnailer spec

[Brian J. Tarricone]

Jannis Pohlmann wrote:

>   This is exactly what e.g. file managers need though. Just imagine a
> file manager enters a directory, queues all its files for thumbnailing
> and then switches the directory before all files are processed by the
> thumbnailer. So IMHO it should be pointed out more clearly that this is
> not a violation of the spec. Right now it just says "You can't unqueue
> requests that are currently running." This should be something like
> "You cannot cancel the processing of individual URIs but thumbnailers
> are free to support cancelling running tasks between the processing two
> URIs when a task unqueued."

Why be so resrictive, though?  For some image types currently-running 
cancellation isn't feasible, but why explicitly disallow it?  If the 
thumbnailer can indeed  interrupt an image decoder/encoder in the middle 
of processing, why not do so?

Better would just be something like:

"Unqueue removes thumbnail requests from the queue.  A service 
implementation is only guaranteed to cancel requests that have not 
started processing yet when it receives the Unqueue request.  A service 
implementation may cancel an in-progress request if possible, but 
clients should not depend on this behavior being available."

The thumbnail server could still emit Finished on the item -- 
immediately if it was able to stop immediately, or later if it had to 
wait for an in-progress request to finish.

I could see this being useful at least on the open/read side of the 
thumbnailer.  Even if you're using gdk-pixbuf, this could be implemented 
by using a GdkPixbufLoader to incrementally load a file, with 
cancellation points every XYZ kilobytes.  For larger images (think 10MP 
photos), this might be a nice thing to have on a slower machine, as 
creating a thumbnail might take several seconds, or more.

Other cancellation points could be after loading but before scaling, and 
after scaling but before saving.

You probably couldn't cancel many thumbnailers in the middle of scaling 
or saving, of course.

> Another thing I noticed is that timestamps passed over D-Bus (e.g. the
> "since" argument to org.freedesktop.thumbnailer.Generic.Cleanup) are 32
> bit unsigned integers ("u") while they should really be 64 bit uints
> ("x"). Philip told me the reason to use "u" was that some D-Bus
> versions didn't handle "x" properly. On the long run there's no way
> around 64 bit ints though, I guess. 

Is it really the case that 64 bit ints don't work with dbus in some 
places?  If this is just pre-1.0 versions of dbus, I don't think it's a 
big deal.  If it's dbus on certain platforms, then that might be a problem.

	-brian