no problem you can cc your asnwer to the mailing list, in fact it can helps other, you're right.
regards Matthieu Robert McQueen wrote: > 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: > >> 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. >> > > Sure, no problem. > > >> 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 :) >> > > If you start to understand things, you could update documentation on the > Wiki to help other people. :) > > >> 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? >> > > 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 > > >> 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. >> > > 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: > http://projects.collabora.co.uk/~monkey/stream-engine-refactor/ > > 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. > > >> Thanks again for your help >> > > No problems. > > >> Matthieu >> > > Regards, > Rob >
_______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
