[Nice] exposing streams and components in the API

[Kai Vehmanen]

Hi,

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
over
> the code again, I'm having second thoughts about this. It means that we
need
> to call agent_find_stream/agent_find_component in a bunch of places (10
and 18
> respectively in the full mode branch).
[...]
> Exposing the stream and the component might complicate the API somewhat.
It
> might involve adding pointers from Component to its stream, and from
Stream to
> 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 
performance impact.

--