[Bug 32609] TpContact should have properties to know subscribe/publish state

[bugzilla-daemon at freedesktop.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
  Status Whiteboard|                            |review-, minor changes
           Keywords|                            |patch
         AssignedTo|telepathy-bugs at lists.freede |xclaesse at gmail.com
                   |sktop.org                   |

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-01-03 05:57:39 PST ---
> + * tp_contact_get_publish_request:

Please document whether/under what circumstances this returns %NULL or "". One
nice set of semantics would be to guarantee that it's non-NULL if and only if
publish-state is REQUESTED; an alternative nice set of semantics would be to
guarantee that it's never NULL (in which case you'd either need a special case
in the getter, or initialization to g_strdup (NULL)).

The doc-comments for the getters should cross-reference to the properties. I
like the wording "Returns: the value of #TpContact:publish-state", personally.

> +      TP_SUBSCRIPTION_STATE_UNKNOWN,
> +      TP_SUBSCRIPTION_STATE_YES,
> +      TP_SUBSCRIPTION_STATE_UNKNOWN,

Can this go above YES if you're given a stupid value from D-Bus? I think it can
- so the limit needs to be G_MAXUINT32. Or, clip out-of-range values to UNKNOWN
whenever you receive information from D-Bus.

I don't like using an enum member as the upper limit: if anything it should be
(NUM_TP_SUBSCRIPTION_STATES - 1) (which is numerically equal, at the moment).

> Simplify contacts-conn by using TpConnectionPresenceType

I'm not keen on this; I know it's only test code, but it's a misleading thing
to do. The point of not using TpConnectionPresenceType is that basically no
connection managers will have exactly one status per TpConnectionPresenceType -
in the general case, a CM will lack support for some of the "important" (i.e.
directly mapped to presence type) statuses, and will have some statuses that
share a TpConnectionPresenceType (e.g. in Gabble, "available" and "chat" (free
for chat) are both AVAILABLE; in MSN, AIUI, "on-the-phone" and "having-lunch"
could both be BUSY, but there is no "busy" as such).

-- 
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.