Re: API update proposal: cancellation notification

[Iago Toral <itoral igalia com>]

On Mon, 24 Jan 2011 16:51:22 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Mon, 2011-01-24 at 15:13 +0000, Iago Toral wrote:
> >  Personally, I found it semantically incorrect to use an error
> >  notification for a cancelled operation when cancellation is not the
> >  consequence of an error. Still, if some other projects are using
> > this
> >  convention I guess that's something I can live with.
>
>
> While I don't like much neither it, I think that from GIO pov, the 
> error
> comes because the operation couldn't be done: if operation can't be
> done, then it's an error, no matter the reason (in this case, reason 
> is
> that it was cancelled).
>
> Note that also, in case of going with (d) actually we are going with 
> (c)
> + (d): cancelled operations emit a "cancelled" signal when they are
> cancelled.

Mmm, good point. That's something I think we should really avoid, 
because if we do that then operations would have 2 finishing points: the 
callback (when they are not cancelled) and the signal (when they are). 
And that's not a good idea IMHO. The whole point of always invoking the 
callback was to ease the operation finalization process after all. I 
guess we could have grilo connect to the signal and invoke the callback 
instead, but sounds kind of tricky and is not what GCancellable users 
would expect...

Iago