Shipping KCall on our first release

[George Goldberg]

On 5 May 2011 15:02, David Edmundson <david at davidedmundson.co.uk> wrote:
> On Thu, May 5, 2011 at 1:56 PM, George Kiagiadakis
> <kiagiadakis.george at gmail.com> wrote:
>> 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.
>
> No need to apologise, this thread wasn't meant to sound like I was
> telling you off just working out where we are.
>>
>> 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.
>>
> A ten minute quick hack or several painful hours?
>
> What's (pleasantly) surprising is that I've heard from two people now
> that it 'sort of works'.
>
> From what you've described there's not much point fixing KCall for a
> while so realistically then we have two choices:
>
>  - Release what we have against the old farsight spec and get a tonne
> of bug reports which we choose to ignore.
>
>  - Wait for the new call spec, which will probably take aaaaaaaaaages
> - but then we'll have some nice components from upstream (I love
> upstream, they're always giving us nice things) and make something
> kick-ass.
>
> I'm struggling to form an opinion. There's advantages and disadvantages to both.
>
> If anyone has any opinions please share them, then I say the two
> Georges should make the final decision.