[Nice] exposing streams and components in the API
dafydd.harries at collabora.co.uk
Thu Oct 4 05:07:25 PDT 2007
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.
> 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/
- 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
More information about the Nice