Re: API update proposal: cancellation notification

[Guillaume Emont <gemont igalia com>]

On 24/01/2011 17:02, Iago Toral wrote:
>
> On Mon, 24 Jan 2011 16:51:22 +0100, "Juan A." Suárez Romero
> <jasuarez igalia com> wrote:
>>
>> 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...
The user doesn't need to have 2 finishing points. If we do it in the
same way as GIO does it, then we would call the callback with an error
*and* the GCancellable would emit a signal. The user can perfectly
ignore that signal if that's not convenient for her, and have the
callback be a unique finishing point, both when cancelled and not cancelled.
The signal is just one more (optional) way of getting the termination
information.

Guij