[Bug 41897] Generate code for Call1

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Olivier Crête <olivier.crete at ocrete.ca> 2011-11-21 18:52:22 PST ---
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.

 * When removing a content, do we have to remove its streams before? should we
assert that the content has no stream when removing it?

I think the user should be able to remove the Content and that should destroy
all the streams/endpoints/mediadescriptions associated with it.

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


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


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

 * tp_base_call_channel_set_state() should set flags and details? Some flags
like RINGING can be handled internally, but not all afaik.
 * tp_base_call_channel_update_member_flags() should emit StateChanged
 * TpBaseCallStreamRequestReceivingFunc should return gboolean for success
 * Why tp_base_call_channel_set_ringing_dbus() does not call a vmethod to let
protocol inform the other side?
 * why is TpBaseCallContent the only object to have a deinit?
 * why does TpBaseCallContent and TpBaseCallStream register themself on the
bus? other TpBase let subclass decide
 * Should tp_base_call_channel_add_content_dbus() assert that vmethod called
tp_base_call_channel_add_content()?
 * Why is initial_audio in public TpBaseCallChannel struct but not
initial_audio_name?

I'll let Sjoerd answer these as I have no clue.

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