<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div> As earlier communicated on pidgin-dev we are doing improvements in a few libraries to make Pidgin shine as a Lync-client. (Leveraging SIPE)<br><br></div> There is some design needed in libpurple in order to make File Transfer and Desktop Sharing, work. Jakub Adam has written a high level design proposal, and we need your comments. I think it is important that we do this in concert with, or with the blessing with those of you who are going to review the work, and incorporate the patches.<br>
<br></div> Our aim is also to do this according to best practices, as generic as possible, taken other backends into account. We hope that our work would also benefit Jabber/Jingle for example.<br><br></div> Here is Jakub's proposal. Your comments are both needed and highly appreciated.<br>
<br><i>Libpurple already uses Farstream in its voice and video subsystem, where it takes care<br>
of establishing a route between the communicating parties and handles media codecs and<br>
I/O devices.<br>
<br>
There are other use cases than voice call, though, that could benefit from Farstream's<br>
functionality. For instance, Google's Jabber file transfer uses connectivity establishment<br>
based on local and remote candidates that FsNiceTransmitter provides. MS Lync utilizes<br>
connectivity establishment and RTP for its filetransfers and desktop sharing.<br>
<br>
Our general idea is to create a common API inspired by current PurpleMedia which prpls could<br>
use to implement the above mentioned and also other features, not only voice. PurpleMedia<br>
is already made a GObject, so we could add some hierarchy to the code, having<br>
PurpleDataConference base class that would implement the common functionality (add stream<br>
and set its parameters, signal accepted/rejected/hangup, functions to read and write data<br>
to streams, get local candidates, add remote candidates, get active candidates).<br>
<br>
PurpleRtpConference (inheriting PurpleDataConference) than could implement sending arbitrary data<br>
through RTP protocol. This would be usable for file transfer or desktop sharing -- conference<br>
object establishes a connection and protocol plugin then reads and writes directly to the stream<br>
(files or RDP protocol packets for example).<br>
<br>
In the end, current PurpleMedia could become a specialization of PurpleRtpConference, adding<br>
codecs into the media pipeline and connecting the streams to audio and video IO devices.<br>
<br>
This way the plugins will be able to just instantiate a conference object of the type which fits<br>
their needs, without having to reimplement everything on their own around Farstream and libnice directly.<br>
<br>
Please tell us what do you think and whether you see any problems.</i><br><br></div>Best regards,<br></div>Jakub Adam/Niklas Andersson<br></div>