On Do, 2011-03-31 at 07:56 +0100, Alvaro Manera wrote: > On Tuesday, March 29, 2011 05:35:04 pm ext Patrick Ohly wrote: > So far the calendar area hasn't been discussed, but I would like to comment > on > a few things... > > In the wiki it says: > > Disavantages of mKCal.
Okay, I knew it was a mistake to include such a comparison. Now that it is public, let's discuss it. > * Only one coarse change method. There is not fine "diff" notifications. I > agree, > this can be improved, and I think it would be quite easy to implement. But > was > it requested anywhere? No. I was merely comparing the current status. > * iCal support was faulty. Well yes it had some bugs, but most of them are > closed only two are open and one assigned to you. Is the bug history a reason > to ditch a project? It certainly leaves a bad impression that fixing bugs like https://bugs.meego.com/show_bug.cgi?id=6050 took 8 months and several false "bug closed" status changes (https://bugs.meego.com/show_activity.cgi?id=6050) before the fix eventually arrived in MeeGo. Now we all know that the situation for fixing bugs in MeeGo was difficult in the past. But can we be sure that it will be better in the future? > Where are the EDS advantages in the wiki? Because the "problems" of the > current solution are stated. But why is eds better? Where are the reasons? I'm not saying that EDS is necessarily better. It's better understood, we know how to fix it if we run into problems. That's all, but that matters. > About the partial loading of mKCal. Is it faulty? Please provide the bug > number. It was faulty: https://bugs.meego.com/show_bug.cgi?id=6061#c5 I still find it hard to use correctly. For example, which events need to be loaded to get a correct response for "events falling into the time range 2011-03-31 00:00 Europe/Berlin until 2011-03-31 23:59 Europe/Berlin"? Which API calls, which parameters? > mKcal also has a quite flexible plugin invitations handling. How do you plan > to > integrate the "new" backend with exchange or any other service? Valid point, but not relevant yet. There is no Exchange support in MeeGo. The UIs on meego.com are barely able to handle basic calendar and email tasks. Handling meeting invitations is out of scope right now. Yes, it is a pity that the more capable UIs taking full advantage of mKCal and QMF capabilities are not in meego.com or the situation would be a lot different. > And with Buteo > also, there was a way to add sync services. How is it planned now? Who needs that? Let me know and I'll add it to SyncEvolution. I've said it before: MeeGo now needs to focus on the things for which there is a real need. Everything else just binds resources which are desperately needed elsewhere. > Continuing with the statements on the wiki. > As I said before KCalCore in meego is from upstream. The modifications are > the > patches we have implemented that haven't been sent to kde's git yet. (or the > ones which hasn't been merged yet from their git). So again FUD. I beg to disagree here. The MeeGo version of KCalCore is compiled differently than the upstream version: #if !defined(KCALCORE_FOR_MEEGO) endDate = kdt.date().addDays( -1 ); #else endDate = kdt.date(); #endif It's minor, but I suspect that if the upstream KCalCore was used in MeeGo, it would break mKCal. I also don't see how upstream would accept such a patch or if they did, why MeeGo should have a different semantic than the upstream KDE version. > Your proposal says that you would use KCalCore for the iCal parsing and use > it > from EDS. Wasn't it said above that the iCal parsing was faulty? Yes, and the ifdef above is part of the fix for one of these bugs. My hope is that once upstream KCalCore is used, it'll have no iCalendar handling issues. > Everything > else is pure FUD to hide a political decision and change a project not > invented here for another one that it is. Minor correction: EDS was not invented at Intel or for Moblin/MeeGo. I'm also not trying to hide a political decision. I was told to investigate EDS for MeeGo, and that's what I am doing. If you disagree with that direction, then please talk to those who decided to go that way. That decision was made way above my head, so talking with me about it will gain you nothing except some clarifications about technical aspects. <rant>In case folks on the list still haven't noticed, I'm sticking my neck out here because I believe that discussions should be open. So far the result is definitely not going to encourage others to do the same. Oh, and I'm on vacation today, I shouldn't even be reading your emails, much less responding to them.</rant> -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
