KDE voice/video communication abstraction?

[Emmanuel Lepage]

Hi,

Thanks for replying. In SFLPhone, all media is done on the server side, so the client side is a light as it can possibly be. This allow us to have very good portability for embedded devices. To display video, the daemon simply share a framebuffer using POSIX shared memory. The implementation is only ~60 line long and work. It is not perfect yet, but it does work. We had the same discussions and problems you had, and it is the solution we took. Because:
-We avoid client side logic when unnecessary
-It is actually simple and portable
-It is not dependent on X11, it is a simple ARGB array with the buffer size and resolution pushed over dbus

The downside are:
-You have to be in sync or it will fall apart
-It bypass dbus, something we would have liked to avoid too

As for the CM, if we implement that http://telepathy.freedesktop.org/spec/Connection_Manager.html, http://telepathy.freedesktop.org/spec/Protocol.html and http://telepathy.freedesktop.org/spec/Channel.html as an alternative DBUS interface for the SFLPhone daemon, it should work (but not the video) as a telepathy protocol without any other modifications?

For the protocols, contacts need to be mirrored on the service side? So we would need a gnome+evolution and KDE+Akonadi implementation.

----- Original Message -----
From: "George Kiagiadakis" <kiagiadakis.george at gmail.com>
To: "KDE Telepathy" <kde-telepathy at kde.org>
Sent: Saturday, June 16, 2012 10:02:55 AM
Subject: Re: KDE voice/video communication abstraction?

On Fri, Jun 15, 2012 at 10:28 PM, George Goldberg
<grundleborg at googlemail.com> wrote:
> On 15 June 2012 20:23, Emmanuel Lepage
> <emmanuel.lepage at savoirfairelinux.com> wrote:
>> Ok, so ConnectionManagers can support all features, configuration, parent/child communication node? Can I re-use some of my Qt/C++ code or I really have to go GObject + C? Do you have advices for me, good example (I found a few like this one http://cgit.freedesktop.org/telepathy/telepathy-salut/tree/src/connection-manager.c http://telepathy.freedesktop.org/doc/book/sect.connection.connection-manager.html). Is it a case of "the documentation is the code" or is there a step by step page to introduce me to ConnectionManagers and telepathy design.
>
> The telepathy book I believe is focused on writing clients (that page
> you've linked is part of the client side-library, so on the other side
> of the abstraction layer to connection managers).  All the connection
> managers that I know of are written in C/GObject, but there's nothing
> theoretically stopping you writing one in Qt.  It's just that a lot of
> the convenience and helper code that's in the telepathy glib library
> won't be available to you.  However, Olli or George K would know far
> more than me about how hard it would be to write a connection manager
> in Qt, so I'll leave it to them to comment officially.
>

As I said in a previous mail, we have some really basic support for
writing CMs in telepathy-qt, but it is not enough even for writing the
most simple non-example connection manager without using the low-level
interfaces. This basically means that you need to go very low level
and implement the dbus interfaces directly, which of course doesn't
mean it's not possible, but it would probably take more time than
writing it with telpeathy-glib. Especially for a case like SFLPhone
where you would need to implement the service-side of the various Call
interfaces, I think it would be better to use telepathy-glib. You can
of course mix Qt and GLib, there is no problem with that. Wrapping the
glib parts with Qt classes can make the job much more pleasant and
easy.

I don't really know if there is any good documentation/guide about
this stuff... The best documentation is probably the telepathy spec -
http://telepathy.freedesktop.org/spec/

Back to the previous discussion, though, I was wondering how SFLPhone
deals with media devices and media streaming. Is it all done inside
the daemon? If yes, how does it deal with displaying video on the UI?
In Telepathy, originally, the idea was to let the connection manager
do everything (including streaming and handling of devices), however
the only way to have video was to let the daemon open an X window and
have the UI embed it, which was a terrible non-portable and
non-expandable design. So, in later versions of the spec, it was
decided to let the UI do all the media handling. My point is, that
even if you try to do a KDE UI abstraction layer, it is difficult to
achieve it, because the UI needs to be aware of the media streaming
pipeline - more or less.
_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy at kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy