Shipping KCall on our first release

[George Kiagiadakis]

On Thu, May 5, 2011 at 1:30 AM, David Edmundson
<david at davidedmundson.co.uk> wrote:
> Just seen a patch for Contact List adding start Audio/Video chat support.
>
> What is the opinion on shipping KCall on our first release (in 2-3
> weeks)? We need to have a solid line of "this is part of the first
> release" or "this is one of the experimental components that you
> shouldn't package". I don't really want to send out other confusing
> messages.
>
> It didn't come up at last weeks meeting, because I'm a massive idiot
> and forgot to add it to the agenda. Right now it's NOT in my "Getting
> Started"  wiki page, and it's also not in George G's "Guide for
> packagers"
>
> Do the audio/video handlers work well enough to ship? I've not
> tested/tried them in ages.
>
> In my opinion, I don't care if they're ugly or even if they crash as
> long as they load. It's showing off all the stuff we (George K) has
> done and it might help generate more interest in doing whatever else
> is needed.
>
> Opinions? (Especially from George K)

Well, let's start from the status. The current master of the call-ui
is an ugly handler for StreamedMedia channels which works for audio
calls (most of the time, given that you have the right gstreamer
plugins installed) and crashes for video calls (unless you are calling
the echo bot). All of the testing was done with gabble, so I don't
know if it works or not with other protocols, but theoretically it
should.

Let's go to the future plans. First of all, StreamedMedia channels and
the telepathy-farsight api for handling them are both awful. I've
spent too much time in trying to understand how they work and writing
code based on assumptions that were never correct. It turns out that
doing calls is far more complicated than what one would expect by
looking at the api and I am tired of trying to reinvent the wheel
every time based on different assumptions. So, I don't have any plans
on continuing to work with StreamedMedia and tp-farsight and I have
already started porting to the Call.DRAFT interface and tp-farstream
(which are way better). This means that nearly all of the code that is
currently in the call-ui master branch is going to be replaced sooner
or later.

I appologize that my work on the call-ui has stopped since February.
The main reason for that is that I am still confused about certain
parts, especially on the UI part (how should it look and behave - it's
not that simple, even if we have mockups -, whether it should use QML
or not, etc...), and I know that Call.DRAFT and farstream are still
going under changes, which may cause me to do extra work for no reason
(I've heard that upstream people are working on some magic gstreamer
elements that will do most of the work for me, for example). As a
result, I am quite demotivated, to be honest.

Back to the topic, I am not against shipping the current call-ui if
you people think it would be nice. However, I am not going to accept
bug reports about it, given that this code is already deprecated. I
can think of a hack that would probably solve the video crashes, so we
might also be able to have some preview of video calls, but that's all
I can do about it.

Regards,
George