Thoughts and planning about KCall's future

[George Kiagiadakis]

Hello list,

Summer has come and I finally have again some time and willingness to
do some more work on kde-telepathy. I am probably going to work on
kcall again, but the problem is that I have no good plan of how things
should be in kde-telepathy and what direction I should follow on my
design. So, I am starting this thread to dump my thoughts and discuss
some things that still trouble me.

What we have now:
KCall currently consists of 3 applications. A contact list, an
approver for the incoming calls and a call handler application (which
shows the window with the video, controls, etc). The handler uses the
StreamedMedia channel interface for handling calls,
telepathy-farsight, farsight2 and gstreamer for the actual streaming.
It's user interface is quite ugly and unusable for end users imho, so
that needs some significant work.

Thoughts for the future:
First of all, the handler should eventually be changed to support the
new Call.DRAFT interface. I am not really interested in maintaining
the StreamedMedia interface, since it's broken by design and makes
things very difficult to code. Gabble already supports Call.DRAFT, and
I think that's enough for now; other CMs will follow as soon as it's
stable. Second, farsight2 and gstreamer will remain (they are the best
solution available for this purpose), but I am thinking to provide my
own implementation of telepathy-farsight, since telepathy-farsight has
many things I don't like (ugly api that doesn't behave nicely, no
Call.DRAFT support yet, extra build-time and runtime dependency on
telepathy-glib for no good reason). Third, for better integration with
the rest of kde, it should be made working flawlessly with pulseaudio,
as we agreed on the multimedia meeting in Randa last week. This is not
much work, given that it can already work with pulseaudio, thanks to
gstreamer, if "Autodetect" is chosen in the device settings, but I am
thinking of reworking a bit the device configuration dialog so that it
doesn't confuse the users too much.

Regarding the user interface, I think the contact list is useless,
since we are going to have a global contact list for kde (right?) and
a question remains about what to do with the approver (i.e. should we
have a separate approver application for calls? should we have some
daemon approving all kinds of channels? something else? we had
discussed that last year with grundleborg and we both agreed to leave
that for later).

The most basic question though is what to do with the user interface
of the call handler. The problem is that telepathy supports many
different use cases for audio/video conference through the same
interface, but on the GUI side they are significantly different and I
think they cannot be handled in the same way.

* One simple use case is the typical case of a text chat between two
persons that can be promoted to have audio and/or video (like in msn
messenger), or the opposite case of an audio/video call between two
persons that can be promoted to have a text chat as well (like skype).
Many people like the idea of having audio/video widgets inside the
text chat UI for this purpose. I had received many comments about this
last year on my blog and on irc, where people asked me if it would be
possible to integrate kcall with the kopete chat and have them in one
window.

* Another use case is the case of an audio/video conference between
many people (i.e. more than 2). Although this is not yet technically
possible, afaik there is an ongoing effort to support this on the
jabber protocol and the new telepathy Call interface has been designed
to make this easier to implement (because with the old StreamedMedia
interface it was almost - if not completely - impossible). In this
case, we need an interface that will take much space, with multiple
video widgets arranged somehow (ideas for that?), and I don't think
this fits in the chat UI.

* The Call interface theoretically can have more contents than just
audio and video, so some CM in the future may support even more
workflows. For example, one could have audio, video and slideshow
contents, for making a presentation live over the internet.

All scenarios have their own design problems. The first scenario is
easier to implement on the UI, but it is not so easy to have the same
application handle both channels (but it's not impossible). The second
scenario is a nightmare to implement on the UI, because you can't know
the exact number of video widgets at design time, but it's easier to
handle the new channel in a separate call-oriented application. The
third use case is hypothetical, but I think if we ever have something
like this, we need yet another UI for it... Obviously, one could say
that the best solution is to have 2 - 3 separate UI applications, one
for each use case. However, when the channel is created, there is no
way to know which one of them to use to handle the channel. Maybe it
could work if we have all of them on the chat UI and let it
dynamically change layout when new participants and contents enter or
leave, but I am not sure how it should look or behave.

So, I would appreciate some feedback on all of this, especially on the
call UI problem, so that I have some general direction on how to
proceed. Obviously the call UI is not something that will be
implemented so soon, as the chat UI is not even written yet, and also
we may want to have a stable kde-telepathy release without audio/video
first, before adding new features, but it would be nice to have a plan
from now. Currently I am mostly interested in converting existing code
to work with the Call.DRAFT interface, before it becomes stable, so
that I have a chance to find possible problems in its design and make
sure that it will rock when it becomes stable! :)

Sorry for the long email...

Best regards,
George