On Tuesday, March 29, 2011 05:35:04 pm ext Patrick Ohly wrote: > Hello! > > Let's be more specific about identifying work which needs to be done. > I've put together some thoughts here: > http://wiki.meego.com/Architecture/planning/evolution-data-server > http://wiki.meego.com/Architecture/planning/evolution-data-server/QtContact > s_storage_plugin > http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-impr > ovements > > The first page does include a very simplistic comparison of the > different options. I thought about leaving out that part altogether, but > decided otherwise because I believe that listing some of the pros and > cons in public is useful. No flame wars, please. > > For contacts and calendar it is fairly obvious where the pain points > are, so let's focus on that for now. I'm interested in getting feedback > on the proposed EDS improvements. > > At this point, I have the QtContacts-EDS contact manager working for > reading and writing contacts, as outlined in the page linked to above. > Change notifications are missing. It's just proof of concept > (non-)quality. I suspect that I need to get open source approval first > before publishing it somewhere. > > I have not done any prototyping yet with KCalCore, but I expect that > similar improvements as for contacts will be useful for that work, too.
Hi, 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. * 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? You are the promoter of FeatureZilla, where is the link? Nobody has ever heard of this feature request. * 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 dich a project? Has EDS a better history? This is FUD and I think having bugs and fixing them is a healthy symptom of a project. 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? About the partial loading of mKCal. Is it faulty? Please provide the bug number. Or is it FUD again? And as it is said in the wiki, eds holds everything into memory. I find this a problem. What happens if a manager type person with an average 4-6 events per day, and a two year calendar? (Roughly 54 weeks * 5days/week * 6 events = 1620 events. Do you need to keep all this in memory? Nowadays memory is cheap, so we could argue that. But, on every startup you have to read one iCalendar text file (as said on the wiki) with all that content?? So how long do you think the startup will be? mKcal also has a quite flexible plugin invitations handling. How do you plan to integrate the "new" backend with exchange or any other service? And with Buteo also, there was a way to add sync services. How is it planned now? 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. 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? Concluding this email... As it has said before, there are no technical reasons to back up the decision of changing backeds. From all the stated ones, only one is valid and it could be implemented (isn't it that easier that creating something new?). Everything else is pure FUD to hide a political decision and change a project not invented here for another one that it is. Please provide real facts why the change is made. Álvaro _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
