[Bug 23492] Implement ContactCapabilities.DRAFT2

[bugzilla-daemon at freedesktop.org]

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





--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-08 04:33:03 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > static TpHandleRepoIface *feature_handles = NULL;
> > Add a comment [...]

Fixed in the branch

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

Fixed in the branch

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

These strings actually only appear in a debug message. The one you complained
about is deleted later in the branch (when I switch from draft 1, which doesn't
have client names, to draft 2, which does) but I've added a comment for the use
of "<legacy Capabilities>".

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

Fixed in the branch, I used /* o.f.T.C.Capabilities */ etc.

> > advertise-caps2.py: do a test with more than 1 client?

I did. AbiWord's caps are set before Connect(), and KCall's are added
afterwards; both clients' caps are then removed, and a couple of versions of
KCall's caps are re-added.

> > Idem in caps/tube-caps.py
> 
> I think doing this in advertise-draft2 would be plenty: it's the same code
> path.

I don't think this is necessary; the general code path for "advertise some
clients' caps" has been tested, in caps/advertise-draft2.py, so we only need to
check the specifics of Tubes 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.
> 
> Good thinking.

I think the correct result is actually "Tubes caps are advertised, but Gabble
is still not callable"; tokens that don't (seem to) make sense for any
supported channel class should just be ignored. I've added a test (which
failed), and corrected the media factory's behaviour to make it pass.

(Conceptually, the set of tokens isn't bound to a channel class - they're
properties of the whole Client, not of any particular channel class.)


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