[Bug 29456] TpAccountChannelRequest: fire-and-forget channel request helpers

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://git.collabora.co.uk/
                   |                            |?p=user/cassidy/telepathy-g
                   |                            |lib;a=shortlog;h=refs/heads
                   |                            |/reques-forget-29456
             Status|NEW                         |ASSIGNED
  Status Whiteboard|                            |review-, minor changes
           Keywords|                            |patch

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-10 06:03:46 PDT ---
Looks pretty good; some minor nitpicking, mostly for the docs.

> +  gboolean handle;

At a glance this looks like it ought to be a TpHandle, not an imperative verb.
Perhaps should_handle?

> +    DEBUG ("Proceed succeeded; waiting the Succeeded signal");

"waiting for the Succeeded signal", or "awaiting the Succeeded signal" (either
is valid)

> + * When the channel has been created and dispatched, @callback will be called.

This sounds as though it always succeeds; perhaps "@callback will be called
when the channel has been created and dispatched, or the request has failed"?

> + * When the channel has been ensure and dispatched (or re-dispatched if the
> + * channel already exists), @callback will be called.

s/ensure/ensured/, but actually I'd say:

"@callback will be called when an existing channel's handler has been notified,
a new channel has been created and dispatched, or the request has failed"

> + * Returns: %TRUE if the channel was successfully ensure and (re-)dispatched,
> + * otherwise %NULL.

s/ensure/ensured/, s/NULL/FALSE/ (the create variant also says NULL)

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