[Bug 47322] [next] GCancellables for all async calls

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47322

Jonny Lamb <jonny.lamb at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #13 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2012-05-10 10:27:42 PDT ---
I think this is pretty clear now that cancellables don't fit in very well here.
Having a cancellable around makes its purpose extremely misleading given the
side-effects still happen.

(In reply to comment #7)
> For APIs that make more than one method call behind the scenes (like a
> Telepathy ChannelRequest), you can cancel and it will actually work, but to do
> that, you need to design your D-Bus API to allow for it, something like:
> 
>     method Start()
>     signal MoreResults(...)
>     method Stop()
> 
> Again, ChannelRequest, FileTransfer and ContactSearch can do this, and perhaps
> so can telepathy-logger (I haven't reviewed its API). For these APIs, sure, the
> async op should be cancellable.

Hmm, really? Say we have an interface called Bong with those three members, is
this the kind of thing you want?

    // calls Start
    void tp_bong_get_results_async(TpBong *,
                                   GCancellable *,
                                   GAsyncResultCallback,
                                   gpointer);

    // fired when MoreResults is emitted
    signal TpBong::got-results(TpBong *,
                               TpBongResult *,
                               gpointer)

    // calls Stop
    GList * tp_bong_get_results_finish(TpBong *,
                                       GAsyncResult *,
                                       GError **);

(or _finish could just not return anything)

So you get an update for any new results so you can update the UI in real time.
Cancelling the GCancellable when you've had enough (or the result you wanted
appeared so the user picked it and closed the dialog, say) is reasonable.

What doesn't feel so right to me is that the async operation taking potentially
minutes. Is this an unnecessary concern of mine?

Anyway, this is a pointless discussion given most of the API isn't designed
like this — I notice TpContactSearch doesn't use this design or GCancellables.

I'm going to mark this as WONTFIX.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.