[Nice] Various questions related to the api

[Olivier Crête]

In the spirit of better late than never,

On Mon, 2007-11-19 at 19:43 +0200, Kai.Vehmanen at nokia.com wrote:
> Hi,
> 
> On 16 Nov 2007, Olivier Crête wrote:
> >> ""- To use the "dribble" mode, client first has to initialize the stream with
> >>   calling nice_agent_set_remote_candidates() with an empty set of 
> >>   candidates, and then start adding new remote candidates with 
> >>   nice_agent_add_remote_candidate().
> >>      - XXX: initial plan, needs review...""
> >
> >I read this, but I didn't like the idea of calling set() with 
> >an empty list, it doesn't feel like a nice API. 
> 
> agreed, I have no problems dropping that.
> 
> >What about just calling add() again with the same candidate 
> >(ie one that has the same ID) ?
> 
> Hmm, that could work. There is no such thing as a candidate ID 
> anymore, but one can (or I guess, should) use the tuple of 
> "IP-address,IP-port,transport-protocol" as a unique identifier. 
> So we could solve the updating problem by having add_remote_candidate() 
> which either adds an entry, or updates if entry matching the "addr,port,proto" 
> tuple exists. Is this ok?

That seems ok to me from the outside. 

> Then to signal that all remote candidates of an offer/answer have
> been delivered, we'd need the "_candidates_added()" method you
> mentioned in an earlier post. So every stream of add_remote_candidate()
> should end with _candidates_added(). Does this still make sense
> for 'old-jingle' clients?

I don't think old-jingle has a signal when all candidates have been
added, but I may be wrong here. I think thats the difficulty,otherwise
we could have just waited for the signal and called set(). 

> But, but, would these be otherwise ok from Farsight-2 point of view?

From Farsight 2's point of view, our main concern is having a nice API.
Currently I have add_remote_candidate() and remote_candidates_added(),
but it can be changed if we find something better.

> One alternative would be to have add_remote_candidates(), but modified
> so that it would update candidates that already exist. IETF clients
> would provide remote candidates of one offer/answer in one go, 
> while dribble-mode clients would call add_remote_candidates() multiple
> times. No need for candidates_added() anymore. Would this work?

Does libnice has to know if its in dribble or regular mode? On the
Farsight2 side, it would be very easy to make the mode a contruct-time
property and then have a single add_remote_candidates() function. This
would seem even better to me.

-- 
Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/nice/attachments/20080124/1db434fd/attachment.pgp