[MeeGo-dev] migration (back) to EDS - contacts and calendar
alvaro.manera at nokia.com
Wed Mar 30 23:56:55 PDT 2011
On Tuesday, March 29, 2011 05:35:04 pm ext Patrick Ohly wrote:
> Let's be more specific about identifying work which needs to be done.
> I've put together some thoughts here:
> 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.
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.
More information about the MeeGo-dev