<div dir="ltr"><div>Hi,<br></div><div><br></div><div>It's been a week since my last mail and since I haven't received any feedback or opposition to my proposal, I will start working on the implementation now.</div>
<div><br></div><div>Thank you,</div><div>Youness.</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 6:09 PM, Youness Alaoui <span dir="ltr"><<a href="mailto:kakaroto@kakaroto.homelinux.net" target="_blank">kakaroto@kakaroto.homelinux.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,<br></div><div><br></div><div>As some of you may be aware, Ericsson and Tieto are working on adding File Transfer and Desktop Sharing support to SIPE plugin for Lync interoperability. Niklas Andersson already wrote previously on the pidgin devel ML to discuss a proposed change to the libpurple API to allow such a feature[1].</div>

<div>I've been assigned to work on the libpurple part of the project and I will be handling the refactor/changes needed in libpurple to allow SIPE to create raw and RTP data streams.</div><div>While Jakub's initial design made sense at the time, I believe there is a better way to do it now considering the recent API change in Farstream to allow for non-audio/video streams[2]. I would like to submit my proposal to the pidgin and jingle developers for review and any comments would be greatly appreciated.</div>

<div><br></div><div>Since Farstream added support for x-data, there's a new session type FS_MEDIA_TYPE_APPLICATION which can be used when creating a session. I suggest we do something similar and add a PURPLE_MEDIA_APPLICATION session type which would allow us to even create a single PurpleMedia with audio, video and data sessions if there is a need for it in the future.</div>

<div>Currently, the purple_media_manager_create_media API takes the conference_type as argument, so for our use case of having a RTP data conference, we would keep using 'fsrtpconference' and create the session with type PURPLE_MEDIA_APPLICATION. In the case of jabber protocol in order to implement google file transfer support, they would use 'fsrawconference' with type PURPLE_MEDIA_APPLICATION and be able to use Farstream and PurpleMedia as an abstraction layer for the libnice library and exchange candidates with it and establish connection without using libnice directly (as was done in Ashish Gupta's branch [3]). </div>

<div><br></div><div>In order to make this work, I plan on changing a few things in libpurple Media/MediaManager. The biggest change will be the addition of a 'private media' system in which a plugin would be able to create a PurpleMedia object and handling it entirely in the plugin without the front-end knowing about it. With the current design, creating the PurpleMedia for our needs would send a init-media signal which would cause the front end to create an audio/video call window, which is why we need to be able to create a private media hidden from the front end. Once a plugin creates a private PurpleMedia, it will then be able to register a data callback or send data to it through a new set of API functions.</div>

<div><br></div><div>here is a summary of the changes I plan on doing : </div><div>- Add PURPLE_MEDIA_APPLICATION as well the PURPLE_MEDIA_SEND_APPLICATION and PURPLE_MEDIA_RECV_APPLICATION</div><div>- Add a new PurpleMediaManager API : purple_media_manager_create_private_media with associated APIs and signals (purple_media_manager_get_private_media, _get_private_media_by_account, _remove_private_media, "init-private-media" signal)</div>

<div>- Add a new set of PurpleMediaManager APIs : purple_media_manager_send_application_data and purple_media_manager_register_application_callback which will be be used/set on a specific PurpleMedia and session.</div><div>

- PURPLE_MEDIA_APPLICATION types will be handled by the PurpleMediaManager and do not need to be registered with purple_media_manager_register_element or purple_media_manager_set_active_element. This is because the source/sink must be appsrc/appsink since PurpleMediaManager will be handling the data send/recv and dispatching to/from the plugins. We also can't allow a plugin or a front-end to override that as it would potentially cause a conflict with other existing plugins.</div>

<div><br></div><div>That's about it, the changes should be fairly small so I don't expect any issues, I also don't believe there is any need for changes in the current purple_xfer API. However, if one of the more seasoned Pidgin developers can see something wrong with this design, or if you have any comments, or suggestions, please let me know.</div>

<div>I am also available on #pidgin IRC channel as 'KaKaRoTo' if you wish to discuss it with me over IRC.</div><div>If I don't get any opposition to this plan in the coming weeks, I'll go ahead and implement it.</div>

<div><br></div><div>Thank you,</div><div>Youness.</div><div><br></div><div>[1] <a href="https://pidgin.im/pipermail/devel/2014-May/023503.html" target="_blank">https://pidgin.im/pipermail/devel/2014-May/023503.html</a></div>
<div>[2] <a href="http://cgit.collabora.com/git/user/tester/farstream.git/log/?h=srtp-xdata" target="_blank">http://cgit.collabora.com/git/user/tester/farstream.git/log/?h=srtp-xdata</a></div>
<div>[3] <a href="http://hg.pidgin.im/soc/2013/ashmew2/filetransferY/" target="_blank">http://hg.pidgin.im/soc/2013/ashmew2/filetransferY/</a></div><div><br></div></div>
</blockquote></div><br></div></div>