[Bug 41897] Generate code for Call1

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Nov 22 10:42:34 CET 2011


https://bugs.freedesktop.org/show_bug.cgi?id=41897

--- Comment #5 from Xavier Claessens <xclaesse at gmail.com> 2011-11-22 01:42:34 PST ---
(In reply to comment #4)
> You should really look at my WIP branch,  I think you're duplicating some of
> the stuff I've already done..... the call1-serviceside branch on my
> git.collabora.co.uk tree.
> 
>  * missing gtkdoc for TpBaseCall*
>  * tp_base_call_*: add g_return_if guards
>  * SetQueued no implemented
>  * add padding to public class structs for future vtable
> 
> There are all in the TODO category.
> 
>  * Shouldn't tp_base_call_channel_hangup() remove all contents for us? or
> assert they are all removed after vmethod?
>  * When hangup the call, should we remove members?
> 
> I think we should leave the channel as is until it closed. I don't really see
> the point of removing members or contents. Note that channel closing may take
> some time after hangup because of the clearing state in cell phone calls.

Note that the spec says: "Request that the call is ended. All contents will be
removed from the Call so that the Contents property will be the empty list." So
we should change spec?

>  * TpyBaseCallChannel implements the DTMF iface, but does all protocal wants
> it? How are CMs supposed to implement DTMF, I see no way for TpyBaseCallChannel
> subclasses to access priv->dtmf_player...
> 
> I have a branch here that removes that dtmf player crap. It should go away
> entirely as all the timing is now delegated to the streaming implementation. My
> branch also implements the Media side of DTMF in TpMediaBaseContent. I think
> TpBaseCallChannel should implemement the interface but let the subclass decide
> to show it in the "Interfaces" property or not.

Ok, I'll pick that from your branch then.

>  * Does mutable-contents==FALSE means we can't add and can't remove contents?
> is it possible to have protocols that can add but not remove or the other way
> around? Is it possible that a protocol can add or remove audio content but not
> video content?
> 
> Afaik, it means they can't change at all. This is mostly for Google Talk and
> some crap SIP servers. Protocols that support partial changes are actually
> negotiated, so you would add it and the other side would remove it.

Ok, so I added a mutable-contents construct-only property on TpBaseCallChannel
and if it is FALSE then AddContent and Content::Remove fails.

>  * Content::remove(): spec says Google Talk video call can't remove content and
> should raise Not Implemented (shouldn't it be NotCapable?) but
> TpyBaseCallContent does not let subclass define if it is supported. Should it
> just check the mutable-contents property?
> 
> I think it should.

ok, it's done like that in my branch now.

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



More information about the telepathy-bugs mailing list