[Nice] API thoughts

[Kai.Vehmanen at nokia.com]

Hi,

On 15 April 2008,  Dafydd Harries wrote:
>> 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 
>
>Oh, perhaps I wasn't clear. I absolutely want to have a good 
>API for single-threaded applications too.

aa, ok, then we are on the same page! :)

>> 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()).
>
>Well, I was thinking that the initial approach could just be 
>to make any handling of inbound STUN packets mutually 
>exclusive. We can make the locking finer later, or perhaps 
>look at using some kind of lock-free update algorithm.

Yes, but you also need to lock the state in all public API 
functions (e.g. in case remote peer restarts the ICE
negotiation), plus in the timer callbacks (which are running
in the "shared context"). But agreed, still very much doable.

>> One alternative would be to expose the socket descriptors for all 
>> stream/components to the client, and then provide thread-safe 
[...]
>> Under the hood, this would of course require similar changes to 
>> libnice implementation (e.g. locking would be needed).
>
>Ah, so the client would run nice_agent_run () in a loop in 
>this case? That could work. I'm more keen to provide a good 
>callback-based API, but exposing the file descriptors might 
>make sense for mainloop-impaired programs.

For me both are valid options (libnice is anyways using glib
timers to maintain agent state).

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