[Nice] API thoughts

[Kai.Vehmanen at nokia.com]

Hi,

On 11 April 2008,  Dafydd Harries wrote:

>Our current idea is to have a new pair of agent methods:
[...]
>  GMainContext *
>  nice_agent_make_recv_context (
>      NiceAgent *agent,
>      guint stream_id,
>      guint component_id,
>      NiceAgentRecvFunc func,
>      gpointer data);
[...]
>The first would create a GMainContext with a GSource for each 
>of the indicated stream's candidates, suitable for a GstSource 
>to run in a mainloop. This provides the ability to stop 
>waiting at any time using g_main_loop_quit ().

... or I guess a set of GSources related to one stream/component
(multiple
candidates may share the same socket)?

In principle this sounds good (in fact
'agent.c:priv_attach_new_stream()'
already creates the GSources this way), but I'm a bit worried about 
how this works for clients which don't want to use different threads
for diffenrt stream/components.

Could we somehow support both models? Or is there a way to run
a set of GMainContexts in a single GMainloop (without writing
a custom GSource for this purpose)...?

>  GMainContext *
>  nice_agent_make_shared_context (
>      NiceAgent *agent);
[...]
>The locking should be quite straightforward, I think.

Hmm, yes, this should be doable. Although the locking has
to be done very carefully (inbound STUN messages affect agent-wide
state in many ways, see conncheck.c:conn_check_handle_inbound_stun()).

>I suspect nice_agent_recv_sock () and nice_agent_poll_read () 
>should be removed.

Yep, agreed. 

One alternative would be to expose the socket descriptors for 
all stream/components to the client, and then provide 
thread-safe nice_agent_run() and nice_agent_recv_sock() methods
(latter would work in a nonblocking fashion, called after 
nice_agent_run()). The client could then either a) poll all sockets 
from a single thread, or b) have a single thread for control and 
then one thread per stream/component. Under the hood, this would of 
course require similar changes to libnice implementation (e.g. locking 
would be needed).

Br,
-- 
first.surname at nokia.com (Kai Vehmanen)