[Nice] New API and refactor

[Rémi Denis-Courmont]

Le Saturday 21 June 2008 00:13:59 ext Youness Alaoui, vous avez écrit :
> Other changes include the fact that the NONCE/REALM/USERNAME attributes
> should be added by the user of the library, and not by the library
> itself.. the STUN module will only add the message-integrity and the
> fingerprint attributes if necessary.
>
> The main problem I see now is with the stun 'bind' and 'stun-ice'
> usages.. those should not be in the stun module, they should be part of
> the libnice core functions and should be a lot simpler.

They used to be simple, until we found half a dozen different cases that need 
to be handled in different ways for different reasons. The "large" number of 
API mostly comes from the fact that we want a non-blocking API, so we have to 
expose the timer and the transaction state (completed, failed, resending, 
waiting for answer...) to the caller. In fact, the blocking API is way 
simpler... but it is obviously not usable within nice/

Then it is also true that, for instance, stun_conncheck_start has an horrific 
prototype. But unless we're to create even more APIs, or expose STUN message 
formatting upstream, we simply cannot remove them. In all three cases (more 
API, expose STUN messages format, change nothing), I'm afraid it will remain 
intricate because it intrinsically is.


As for being part of the core - I have to disagree. Binding discovery is part 
of STUN. Logically: it avoids exposing the STUN message formats to ICE. 
Architecturally: it is part of the STUN spec, not the ICE one. In real life: 
it can be used independent of ICE. For testing purpose: it is a lot easier to 
test in-depth without booting the full ICE layers.

The STUN-ICE usage is a corner case. It is of course ICE-specific. We put it 
to the STUN part because it had a lot of common code with the binding 
discovery, and because we did not want to expose (as far as possible) the ICE 
agent to the STUN messages.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D