On Wed, May 11, 2011 at 6:03 PM, Daniele E. Domenichelli < [email protected]> wrote:
> On 05/11/2011 06:09 PM, David Edmundson wrote: > > *270672: Channelhandler daemon for file transfers > > * > > Dr Danz started this, hit some issues which means we'll only get working > > support in Jabber. Also requires a change in TpQt4. We can't ship until > > this change is merged into TpQt4 and they make a release. This is > > probably going to be the biggest hold-up. > > > > Could we try and make sure any work gets pushed to somewhere on kde git. > > This is the blocking bug in TpQt4: > > https <https://bugs.freedesktop.org/show_bug.cgi?id=37034>*:// > bugs.freedesktop.org/show_bug.cgi?id=37034* > > I can work on that bug, but I require some feedback from TpQt4 developers. > oggis_, andrunko: ping ^ :D > > > Caught Andrunko on IRC: [22:01] <andrunko> d_ed, the approach seems ok, just add a new constructor and a setURI, etc as needed there and pass the info when requesting the FT channels [22:01] <andrunko> and do not remove or deprecate current ones [22:04] <andrunko> d_ed, also obviously add a FT::uri() accessor, so handlers can get the uri passed As far as I understand it that's exactly what we wanted to hear (options 1&2 of your bug report), but they're not allowing any changes which break binary computability (understandably). > > Moreover the only connection managers that support the URI property at > the moment seem to be gabble and salut therefore, file transfer will be > supported only by those connection managers (unless we add some sort of > ugly hack). > > > > Most of the handler is already written, therefore I believe that if > TpQt4 bug is resolved we can ship it with the first release. > > By the way, as discussed on irc, I'm implementing it as a one-shot file > transfer handler (no daemon), therefore as soon as the channel is > received it will unregister from D-Bus and start the file transfer and > exit as soon as it finishes. > If a new file transfer channel is received, a new instance of the file > transfer handler will be started by MC. > > I believe that this is the best way to do it because: > > 1) A crash in one process won't kill all the other file transfers. > 2) There is no daemon running all the time and no need to check if it > is possible to exit or if there are more transfers running. > 3) There shouldn't be racing condition with handler exiting/new file > transfers channel sent by MC (I'm not sure if there could be a > racing condition with handler unregistering/new file transfer > channel sent by MC). > > If someone believes that this is wrong or has anything to tell about > this issue, please speak now... :D > > > > *270673: Support FileTransfer channel types [ in approver] > > * > > I've not heard of any work on this. Probably waiting on the > > channelhandler. I think it's pretty trivial though. > > I started writing that, and I believe that also George K. started, but > the main issue for this is that popup notifications can be hidden by the > user... > > > > Cheers, > Daniele > _______________________________________________ > KDE-Telepathy mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-telepathy >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
