<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
no problem you can cc your asnwer to the mailing list, in fact it can
helps other, you're right.<br>
<br>
regards<br>
Matthieu<br>
<br>
<br>
Robert McQueen wrote:
<blockquote cite="mid46532161.20603@collabora.co.uk" type="cite">
<pre wrap="">Hi Matthieu,
Was it intentional that you replied to me off the list, or are you happy
for me to CC my answers there so they might help others too?
Matthieu LAURENT wrote:
</pre>
<blockquote type="cite">
<pre wrap="">First of all, thank you for your answer.
I am new in the world of open source, so thank you for educating me and
giving me some advises.
</pre>
</blockquote>
<pre wrap=""><!---->
Sure, no problem.
</pre>
<blockquote type="cite">
<pre wrap="">I am also new in the telepathy world. I understand more and more things
but there are still some interactions between processes
(telepathy-cilent (tp_caller), connection-manager, stream-engine) that
are not clear, and some details I don t understand... but I am working
on it :)
</pre>
</blockquote>
<pre wrap=""><!---->
If you start to understand things, you could update documentation on the
Wiki to help other people. :)
</pre>
<blockquote type="cite">
<pre wrap="">So the telepathy-client (tp_caller, or another on) can directly call
methods of the stream-engine, without passing through the
connection-manager. Am I right?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, there are three "directions" of communication.
C
Client <---> Stream Engine
|\ /|
\ /
A \ / B
\| |/
Connection Manager
A: The client talks to the connection manager to arrange the call, which
streams and their media types, etc
B: The connection mananager talk to stream engine to communicate the
codecs and networking information necessary to establish the call.
C: The client talks to the connection manager to see the state of the
streams, which are
</pre>
<blockquote type="cite">
<pre wrap="">the example of the duration was just an example.
I may want to inform the telepathy-client of current delay in
communication; percentage of rebuffering in the buffer-jitter queue...
What is the best way to bring this information from the stream-engine to
the telepathy-client?
Send regularly signals from the stream-engine that will be caught by the
telepathy-client (without passing through the connection-manager)?
If yes, this means, as you said, add some signal to the stream engine's api.
</pre>
</blockquote>
<pre wrap=""><!---->
Right, you can add API to stream engine if you want to keep using the
architecture above. For more advanced usages, you might be more
interested in the work in this branch:
<a class="moz-txt-link-freetext" href="http://projects.collabora.co.uk/~monkey/stream-engine-refactor/">http://projects.collabora.co.uk/~monkey/stream-engine-refactor/</a>
Although it's not complete, the plan there is to seperate out the parts
of stream engine which just relay information between Farsight (the
streaming library) and the Telepathy streaming API. These can then be
moved into Farsight or a seperate library, which can be used by a
Telepathy client who wants closer access to the Farsight API, monitoring
the Jitter Buffer, etc.
If you need more control than the stream engine API allows for, this
approach might be more elegant than adding more and more stuff to the
API. Some of what stream engine does is quite specific to the Nokis N800
internet tablets, and we think a library would be far more useful in
other situations.
</pre>
<blockquote type="cite">
<pre wrap="">Thanks again for your help
</pre>
</blockquote>
<pre wrap=""><!---->
No problems.
</pre>
<blockquote type="cite">
<pre wrap="">Matthieu
</pre>
</blockquote>
<pre wrap=""><!---->
Regards,
Rob
</pre>
</blockquote>
<br>
</body>
</html>