[Nice] exposing streams and components in the API

[Dafydd Harries]

Ar 03/10/2007 am 10:57, ysgrifennodd Kai Vehmanen:
> yeah, this would definitely ease splitting up the agent code.
> I made a few attempts while writing the fullmode patch to move
> more code from agent to stream/component side, but you easily
> ended up having to refactor quite a bit of the code (to get
> sane dependencies from Component and Stream back to Agent). So
> I basicly gave up and the current fullmode branch doesn't
> change the basic relations between Agent/Stream/Component objects.

The current API is quite simple.

> So my current understanding is that the current approach is the way
> to go still. It has one big advantage: a single object API (agent.h)
> is simpler for client developers to understand. Be sure to check
> nice/doc/design.txt in the fullmode branch.

Will do.

> Also, some of the functions (set_remote_candidates, adding/removing
> streams) do have agent level impacts, so it also makes sense to
> have these go through the agent object. 

Right, so if we were to move these methods, then we would need to have
pointers from component -> stream -> agent.

> I guess having direct access to the Component/Stream objects would be 
> most useful for payload i/o part of the public API. With these,
> avoiding the ints->objects lookup also has some potential real-life 
> performance impact.

Perhaps it's worth trying to write some sort of tool to try and measure this.

At any rate, I think there are some lower hanging fruit for improving the API
that we should investigate before exposing more objects. Some ideas:

 - including (a pointer to) the NiceCandidate structure in the new-candidate/
   new-remote-candidate/new-selected-pair signals

 - remove the socket factory parameter from nice_agent_new (), and making the
   agent construct a UDP socket factory by default; if it needs to be
   overridden, the socket-factory property on the agent can be set

-- 
Dafydd