[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

--- Comment #6 from Xavier Claessens <xclaesse at gmail.com> 2011-01-09 06:58:13 PST ---
(In reply to comment #5)
> > + * 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)).

With current implementation, it is guaranteed to be non-NULL once the feature
is prepared. I think that's a reasonable behavior. I added documentation for
it.

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

Fixed

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

Ok, I changed to be in [0, G_MAXUINT]. If/When we want to restrict the values,
we could use mkenum anyway.

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

Ok dropped that commit

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