Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell: > Hi Paivi, > > (taking this back to my original thread) > > On Thu, Oct 27, 2011 at 5:08 PM, <[email protected]> wrote: > > We thought that having an integer QContactLocalId is a bit too restricting. > > E.g. if you have a uuid as backend contact id (as the case is in JsonDb > > backend), > > it's lot simpler to treat it as a string than as an integer. Changing > > QContactLocalId to QString was the first step in trying to make contact > > ids a bit more flexible. > > OK. Believe it or not, I agree. I've had to write a UUID-to-integer > translation in my own personal engine plugin, and for instance I > believe qtcontacts-eds had to do a uuid fetch request on startup and > generate a QHash mapping their UUIDs to integers, too.
Well, for qtcontacts-tracker we found a reasonable solution to represent local ids as integers. Well, but actually we also lost quite some hairs until we found our solution - by chance, I have to admit: Tracker exposes the row ids of its internal database. So yes, turning the local id into something string like would make much of sense. Playing the devil, what speaks against QVariant? Would give backends with native numeric contact ids the chance to save a few resources. > > Another step towards that direction would be to hide the internal format of > > backend contact id by providing a wrapper class for backend ids. This > > pattern > > has been used in Organizer, see > > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemengineid.h > > and > > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemid.h. > > This might make sense. Just keep memory constraints in mind. I don't > know about typical organizer patterns, but often, applications dealing > with contacts are forced (for various reasons, efficiency, etc) to > keep a memory representation of a large number of contacts in memory. > If you're heap allocating IDs (as well as all their details etc) - > that's another penalty you're going to pay in terms of performance. > Probably not *that* huge a concern, just make sure to measure first. > :) Cannot you explain the idea behind this? I cannot follow right now. > > About source-compatibility... As a Qt5 AddOn module QtPim has little less > > restrictions > > regarding source-compatibility than Essential modules, see e.g. > > http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition. > > While we try not to break source-compatibility if it's not necessary, we > > also see moving from QtMobility to QtPim as a good opportunity to simplify > > QtPim > > APIs a bit and to make some other changes, which might be more difficult > > later. > > Some of the changes are already visible in qtpim repository, some are still > > in the > > planning phase. We will tell more about the changes and reasoning behind > > them in the near future. > > OK. > > You should probably also talk to some of the Harmattan contacts guys > if you haven't already (of which I am one, a few other of which I've > CC'd). They may have some other ideas on potential changes for > source-incompatible Qt 5 changes. We definitely would have benefited from an offical approach for introducing custom requests: https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/contactlocalidfetchrequest.h https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/contactmergerequest.h https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/lib/unmergeimcontactsrequest.h The solution we found to work around QtContacts limitations is... hideous: https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/engine.cpp#line1794 https://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/contactidfetchrequest.cpp#line52 Ciao, Mathias -- Mathias Hasselmann <[email protected]> http://openismus.com/ _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
