On Wed, 2011-03-09 at 23:24 +0100, Mathias Hasselmann wrote: > Am Mittwoch, den 09.03.2011, 07:30 -0800 schrieb Arjan van de Ven:
> So speaking about qtcontacts-tracker: Can you point me to bug reports, > to or broken promises? > > A quick search for "qtcontacts-tracker" on bugs.meego.com finds 19 bugs. > Not a single show stopper judging from summaries. Nokia's internal bug > tracker lists 17 bugs for qtcontacts-tracker right now. Our test suite > (about 10k lines of code) reports 139 of 139 passed. > > So what actually are the show stoppers? We are now adding support for REPLACE in Tracker's SPARQL Update engine. We know that qtcontacts-tracker had to use a lot of DELETE-WHERE-INSERT constructions and it's likely that the DELETE-WHERE part and old values check of INSERT is a major contributor to the Update performance for qtcontacts-tracker's use-cases. I think Adrien Bustany has started experimenting with this branch today. So if Update performance is a show-stopper we will have new numbers this week. I made an article explaining how the current syntax works: http://pvanhoof.be/blog/index.php/2011/03/09/a-replace-extension-for-trackers-sparqls-update Note that qtcontacts-tracker can also, on top of the REPLACE that we're adding this week, use UpdateArray (it's not yet doing that, afaik). UpdateArray can be instrumental in reducing D-Bus traffic and calls (as you pack multiple queries per call and yet you get per-query errors). Note that we already use FD passing to avoid most of D-Bus's performance problems. > Where is the email telling us qtcontacts-tracker developers that there > are show stopping issues? At least Patrick knows very well how to > contact us. Yes, we did see "some" E-mails on Tracker's upstream mailing list by people from Intel. We also received a few patches and thanks to that we gave priority to our UpdateArray API, then reworked their patch to fit this. But never any performance figures, requirements, big problems, etc. It's very hard to claim that we are unresponsive towards Intel. There's plenty of mailing list material to back that up. I also do wonder where these 'discussions' that Arjan talked about took place. Respected people, like David Neary, have asked the same question in this meego-dev ML thread: On Tue, 2011-03-08 at 12:01 +0100, Dave Neary wrote: > Hi, > > Arjan van de Ven wrote: > > Time has come and gone for this to be a discussion; this is a decision. > > Out of interest, when was the time for this to be a discussion? And > where did that discussion happen? > > Thanks, > Dave. But I see a pattern here: all our questions are left unanswered or have so far been answered by emotional responses. But hey, fine. Been there, done that (Fremantle -> Harmattan). > PS: To get some more numbers I ran few quick searches on bugs.gnome.org: > > ":evolution-data-server :contacts" finds 70 bugs > ":evolution-data-server" even finds 354 bugs Nod. And it's not that several years ago at Nokia, during Fremantle, people where 'satisfied' with EDS. I haven't seen huge improvements happening to EDS since that period. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
