On Mi, 2011-05-11 at 07:12 +0100, Christophe Dumez wrote: > Hi, > > Please find attached two patches for QtContacts EDS backend: > 0001: Make the QContactAbstractRequest::start() method return a > boolean so that the caller knows when an error occurred and the > request could not be started. > 0002: Make the QContactFetchRequest and QContactLocalIdFetchRequest > really asynchronous to improve performance. Tests were updated to > check the functionality.
Looks sane. Merged. > I have a question for you Patrick. Is there a reason to keep the > "#ifdef SUPPORT_HASH" everywhere in QContactEBook? > The hash support code is no longer needed due to your EDS id patch > afaik and this code is outdated anyway. If QtContacts-EDS is ever meant to work with a) non-file backends or b) a file backend which has longer IDs (perhaps because they were created before upgrading to EDS with the 32 bit patch), then hashing will be needed again. I think we can rule out a) for MeeGo, at this time at least. Case b) is harder and has no good solution, except avoiding it. This affects MeeGo Netbook, which is the only vertical which already uses EDS. We should not break it (and adding the 32 bit patch to EDS doesn't) but IMHO we don't need to make QtContacts work on an old installation. Upgrades from one MeeGo release to another without reinstallation has never been guaranteed to work and/or tested. This is just another example of things which do not quite work. > I ask because it would really make the code more readable if I could > get rid of this part. Let's remove it. With all the rewriting of the code, the original design for the hashing probably makes no sense at all anymore anyway. Besides that, it also has the conceptual issues mentioned earlier (no checks for hash collisions). -- 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
