Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Tue, 2008-09-09 at 13:08 +0200, Kevin Krammer wrote:
> On Tuesday 09 September 2008, Philip Van Hoof wrote:
> 
> > I would perhaps accept an amendment to the specification mentioning the
> > possibility of canceling *some* of the thumbnailers's tasks. Without any
> > guarantees for success.
> 
> Right. IMHO you focus too much on a specific and very low level interpretation 
> of cancellation. In a lot of cases the cancel should just stop processing the 
> queue as soon as possible.

I'm fine with adding amendments that state that cancels might be
available, but don't have to be available. IF it's clear that it's a
*might be available* not a *will be available*.

That way it'll be a loose specification (the cancel part), but if it's
absolutely clear that it's *might be available*, then nobody will expect
any guarantees. Which is what I want for this one (you do too, so it
seems).

In the end is a specification a contract. A contract means guarantees.

If I buy a house and my contract is vague, then I shouldn't have bought
the house. If a project manager decides to target a specification but
the specification is vague, it means the project manager shouldn't have
picked that specification (and good project managers wont).

It's really the same thing, although freedesktop claims to be "not a
formal standards body". That doesn't mean that its standards aren't to
be fulfilled by the implementers. A lotof bad implementations can render
a good specification irrelevant (ie. IMAP has this problem atm).

And the very fact that freedesktop ain't claiming to be a formal body
for standards, makes the task of specifying a specification that *will*
be implemented correctly, harder. Which might not be a bad thing,
because that means that better and more simple specifications are
produced - no IMAP-like stories -

I don't see the point in a specification if nobody is going to implement
it right anyway.

SO

A cancel method must be annotated as: this is a might, not a guarantee.

As I *know* that a lot of implementers wont even try to get it right.

> I am quite confident that nobody will assume "stop right after this machine 
> instruction".

So your cancel will be ...

At some point in time, it will cancel.

Okay, then I make a cancel that cancels right after the thumbnail's
generation *is*  finished. That fulfills your contract, doesn't it?

But will you be happy?

I guarantee you implementers will do this if you specify it in such a
vague way.

I wrote E-mail clients for IMAP. I know what implementers are capable of
when it comes to "interpreting a specification for their own benefit".

> If one delegates processing to a service, cancelling is the method of 
> conveying that you are no longer interested in a result.

But it's possible that `Ready` signals got sent already. And since your
cancel is vaguely defined as "at some point in time, it'll cancel": why
shouldn't I just keep sending the `Ready` signals until the generation
of the thumbnail *is* finished.

In other words: don't implement cancel at all.

That's completely correct according to your vague spec for cancel.

So what was the point of specifying cancel in the first place then?

> I don't think it depends on an implementation detail such as thread-based or 
> process-based to tell a worker to stop at the next checkpoint it reaches.
> Just because it is technically possible to hard kill a process doesn't mean 
> will ever want to do that since one can easily create stale lock files, SHM 
> semaphores, etc. that way.

Checkpoints are the cancel points that I've been using in previous
E-mails. All my remarks about cancels points apply to check points too.

Cancel (check) points are, by the way, hard. They require the entire
outside and inside API of your frameworks to cope.

Like GCancellable in GIO and GVFS (I don't know what KIO has for this).

Not all thumbnailers can use this.

> Since there is usually more than one way to implement a thumbnail algorithm, 
> having a spec with cancel capabilities gives hint to developers of such 
> implementations that they should probably think about where to put check 
> points.

That's true. 

So for the hint, I'd approve an amendments that hints that a cancel
might be available. 

And, therefore, a high quality thumbnailer implementation would have
cancels this way.



So send me proposals for a cancel DBus API ...

Note that you need to take into account the specialized thumbnailer's
DBus interface too.


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