[Nice] exposing streams and components in the API
kai.vehmanen at nokia.com
Wed Oct 3 00:57:19 PDT 2007
On Fri Sep 28 2007, Dafydd Harries wrote:
> When I designed the agent API, I made the decision to hide the
> stream/component structs and have them be referred to only by ID. Looking
> the code again, I'm having second thoughts about this. It means that we
> to call agent_find_stream/agent_find_component in a bunch of places (10
> respectively in the full mode branch).
> Exposing the stream and the component might complicate the API somewhat.
> might involve adding pointers from Component to its stream, and from
> its agent, which is a bit smelly.
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.
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.
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
More information about the Nice