Re: API update proposal: cancellation notification

[Iago Toral <itoral igalia com>]

On Mon, 24 Jan 2011 17:17:43 +0100, Guillaume Emont <gemont igalia com> 
wrote:
> 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.

Oh ok, I was misunderstanding how this works then. This is definitely 
better.

Still, in general I am not a big fan of APIs that give you various 
options to do the very same thing. Then it is always up to the app 
developers to be consistent in how they use the APIs, and if they are 
not (which is usually the case) then things become messy and more 
difficult to maintain.

But all in all, I guess having our own code for handling operation 
cancellation, as we have now, is even worse than that.

Iago