It's not immediately obvious how to drive StreamedMedia; in particular, the state changes are poorly documented. My branch at http://people.freedesktop.org/~wjt/telepathy-spec-clarifications/spec/ adds an introduction to the Reason enum, rewrites the SM introduction to be considerably more informative, and references the latter from MembersChanged[Detailed].
I've tacked on a few more patches, spelling out more explicitly how DBus_Property parameters work.
I was just speaking to Marco, and he didn't know that you can tell whether a call is incoming or outgoing by comparing InitiatorHandle to yourself and/or TargetHandle. This should go in there somewhere.
(In reply to comment #2)
> I was just speaking to Marco, and he didn't know that you can tell whether a
> call is incoming or outgoing by comparing InitiatorHandle to yourself and/or
> TargetHandle. This should go in there somewhere.
Isn't Requested a simpler way to do this?
(In reply to comment #3)
> (In reply to comment #2)
> > I was just speaking to Marco, and he didn't know that you can tell whether a
> > call is incoming or outgoing by comparing InitiatorHandle to yourself and/or
> > TargetHandle. This should go in there somewhere.
> Isn't Requested a simpler way to do this?
Yes. I have updated the branch with a new patch explicitly documenting Requested being used for this (and also a patch adding shorthand for org.freedesktop.Telepathy in dbus-ref namespaces).
Marco, would http://people.freedesktop.org/~wjt/telepathy-spec-clarifications/spec/Channel_Type_Streamed_Media.html#description have answered all your questions and filled you with glee? I guess it doesn't mention TargetID (which IIRC you also didn't know about); I think the Channel interface description should have a big table of all the immutable properties every channel has.
(In reply to comment #4)
> I think the Channel
> interface description should have a big table of all the immutable properties
> every channel has.
Thanks, this mostly looks good.
> + from the group. A client may supply a reason when attempting to
> + remove members from a group with
> + <tp:member-ref>RemoveMembersWithReason</tp:member-ref>, and are
> + supplied by the CM when emitting
s/and are supplied by/and reasons are supplied by/ for better grammar?
> Document that locally timed out calls should also be No_Answer.
I think we should also clarify that the CM shouldn't do this unless it has to? Our position on this has generally been that the timeout is policy, therefore it's a UI decision, so if anything gives up, it should be the UI, with RemoveMembersWithReason([SelfHandle], No_Answer).
(I can see that some CMs might not have any choice, if a server or oFono or whatever does the timing-out, though.)
In Gabble, we historically had a 1 minute timeout, which Daf removed in 2009 (late in the 0.7.x series) to fix Bug #21153.
>+ namespace = namespace.replace('ofdT.', 'org.freedesktop.Telepathy.')
I'd prefer this to be anchored at the beginning:
namespace = 'org.freedesktop.Telepathy.' + namespace[5:]
fixed these, i have, hmm?
Indeed you have. Ship it.
Merge: 5492810 df57c2a
Author: Will Thompson <firstname.lastname@example.org>
Date: Tue Jul 13 15:30:39 2010 +0100
Merge branch 'clarifications'
Reviewed-by: Simon McVittie <email@example.com>
Makes-everything-clear-for: Marco Barisione <firstname.lastname@example.org