Review of the thumbnailer spec

[Philip Van Hoof]

On Thu, 2009-05-14 at 19:19 -0700, Brian J. Tarricone wrote:

[CUT]

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

Unqueue is allowed to do this. Just don't add the canceled item to any
of the Ready signals that you emit, and immediately emit Finished.

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

Yeah, for example

> The thumbnail server could still emit Finished on the item -- 

It "must" emit Finished, not could. And Finished happens on the entire
task, not individual items (but maybe that's what you meant). Ready
happens per item, or per group of items (up to the implementer of the
thumbnailer: you can have multiple Ready signals per task, that's fine).

[CUT]

(agreement)

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

I had this problem in the Maemo SDK of the Nokia 810. Maybe this got
fixed though, need to recheck. I shouldn't have changed the official
spec because of it, I agree (it must be x, period).


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