[Bug 23492] Implement ContactCapabilities.DRAFT2

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=23492





--- Comment #2 from Alban Crequy <alban.crequy at collabora.co.uk>  2009-09-08 02:07:12 PST ---
Review not finished, but so far I have some comments:

src/capabilities.c
static TpHandleRepoIface *feature_handles = NULL;
Add a comment to say the content of this pool is not TpHandle in the meaning of
the Tp Spec, but we just reuse the ref-counted string pool implementation which
is called TpHandleRepoIface.  

      DEBUG ("not emitting signal: not connected yet");
Do not confuse with dbus signal: s/signal/presence stanza/

gabble_caps_channel_manager_represent_client(): Why is it called like this? Why
"represent"?

"<ContactCapabilities.DRAFT1>"
Add a comment to say this string is choosen to not conflict with a possible
well-known telepathy client name

In _emit_capabilities_changed():
The comments /* Capabilities */, etc.: use the full name org.f.T.... or at
least write /* Deprecated interface Capability */ because it is not clear it
refers to the D-Bus interface.

+      /* for now, accept either the current InitialAudio (which is in
+       * the FUTURE) or the hypothetical final version */
Does NewChannels signal put both FUTURE and hypothetical final properties too ?
If not, it looks non-consistent

At different places: use g_value_array_get_nth() instead of "GValueArray->va +
n"?

advertise-caps2.py: do a test with more than 1 client?
Idem in caps/tube-caps.py

Test with a client which advertise a tube channel with audio/video token caps
(sic). Gabble should not add that in any channel class since it is invalid.


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