[Bug 23492] Implement ContactCapabilities.DRAFT2

[bugzilla-daemon at freedesktop.org]

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





--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-08 04:11:12 PST ---
(In reply to comment #2)
> 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.

Will do.

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

I'll fix that.

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

The reasoning was "convert the client's capabilities to their XMPP
representation".

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

Will do, although I don't think that's very important tbh.

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

I'll try to provide some better wording.

> +      /* 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

No, the NewChannels signal only has the current (draft, FUTURE) properties; but
I hope that we can undraft InitialAudio/InitialVideo simultaneously with
ContactCapabilities, in practice.

The rationale for accepting a hypothetical final version of IA/IV is that it
gives this Gabble compatibility with more clients; on the other hand, we could
just hurry up and undraft this stuff.

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

I find the latter form clearer; some of the "helpful" GLib macros like
g_value_array_get_nth just obscure what's happening, IMO.

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

I think doing this in advertise-draft2 would be plenty: it's the same code
path.

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

Good thinking.


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