Releasing KDE Telepathy In May

[David Edmundson]

On Wed, May 11, 2011 at 6:03 PM, Daniele E. Domenichelli <
daniele.domenichelli at gmail.com> 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
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110512/d7bb6ff5/attachment.htm