On 5 May 2011 15:02, David Edmundson <[email protected]> wrote: > On Thu, May 5, 2011 at 1:56 PM, George Kiagiadakis > <[email protected]> wrote: >> On Thu, May 5, 2011 at 1:30 AM, David Edmundson >> <[email protected]> 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.
>From what George K said, it sounds like shipping the call UI will probably be a bit of a trap (we'll end up having to put a lot of time into deprecated code, or piss off the early adopters by not caring if the call-ui doesn't work for them). -- George _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
