[Telepathy] telepathy: problem fro accessing stream-engine

[Matthieu LAURENT]

Hi Robert
> Hi Matthieu,
>
> Please don't repeatedly post the same question to the list. This thread
> is now 14 deep in my mail client, and only has 4 or 5 posts which are
> not from you, so I think most people might not even have seen that you
> were posting there any more. It might help that if you have a new
> question, start a new thread.
>   

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.
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 :)
> That said, nobody is under any /obligation/ to help you, although we are
> happy to help people if they are polite and have reasonable questions.
> If you are using Telepathy for a commercial project and /require/ a
> support arrangement, you might follow the link off the Telepathy
> homepage to Collabora, who can offer commercial support for users of the
> project.
>
> You might also note that tp_caller is just a piece of test/example code
> released by Nokia as part of tp-sofiasip, and isn't a very good thing to
> try and ask for detailed information about using - we don't know much
> about it at all. The Python examples call.py and call-gtk.py in
> telepathy-python/examples/ are a much simpler starting point to
> understand the APIs you're trying to use.
>
> Matthieu LAURENT wrote:
>   
>> I don't see any binding in libtelepathy in order to access interface
>> org.freedesktop.Telepathy.StreamEngine, method SetOutputVolume for example
>>
>> Could you tell me how to add this functionality in libtelepathy, and how
>> to call it from the telepathy client tp_caller, in oder to access
>> directly to the whole interface of the stream-engine (or if there is a
>> simplest way to access this function SetOutputVolume)?
>>     
>
> You can see the whole D-Bus API of stream engine by introspecting it
> over the bus, or by viewing
> stream-engine/generate/xml-modified/tp-stream-engine.xml. This API is
> specific to stream engine, and isn't a part of the Telepathy standard,
> which is why libtelepathy doesn't contain it. You can either use
> dbus-binding-tool on the XML file and generate the same kinds of headers
> that libtelepathy contains.
>
> Alternatively, for simple usages you can also use dbus-glib directly to
> make calls to these functions by making a DBusGProxy and use
> dbus_g_proxy_call (proxy, "MethodName", G_TYPE_FOO, foo, G_TYPE_INVALID,
> G_TYPE_BAR, &bar, G_TYPE_INVALID) for a method called MethodName which
> took a FOO argument called "foo" and returned a BAR argument called "bar".
>   
ok I understand what you mean. I can create a binding like libetelpathy,
that will make easier calls to stream-engine, or directly call the dbus
interface thanks dbus-glib.


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?

> Elsewhere, Matthieu LAURENT also wrote:
>   
>> If I would like the stream-engine to bring back information to the
>> telepathy client tp_caller, for example current duration of the call.
>> What should I implement?
>> Can the information be addressed directly to the telepathy client
>> tp_caller or must it passed through the connection-manager?
>>     
>
> At the moment, you should just start a timer when a) the call is
> accepted (the MembersChanged signal is emitted on the channel and both
> members of the call are no longer local or remote pending) and b) the
> Receiving signal is emitted by Stream Engine, indicating that packets
> are being received.
>
> I am going to add some kind of StreamStateChanged signal to Stream
> Engine's API which will tell you when the stream is either Sending *or*
> Receiving. This fixes a minor issue with just looking at the Receiving
> signal - in some cases you don't think the call is in progress until the
> remote end makes some noise and sends some packets.
>   

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.




>   
>> thanks for your help
>>
>> Matthieu
>>     
>
> Regards,
> Rob
Thanks again for your help

Matthieu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20070522/0022e5b4/attachment-0001.htm