[Development] QContactLocalId in Qt5

[Robin Burchell]

Hi Paivi,

(taking this back to my original thread)

On Thu, Oct 27, 2011 at 5:08 PM,  <paivi.rajala at nokia.com> 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.

I don't believe, however, that QString is the data structure you want.
It's utf16 encoded, which means, assuming your UUIDs are 128 bit
integers, you'll be storing 32 bytes per QContactLocalId, which is an
awful lot of RAM to waste when you scale that up to, say, a few
thousand contacts (which is not out of the question...).

If I were to submit a change altering this to QByteArray, would it be accepted?

> 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.
:)

> 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.

thanks,

Robin