[Development] QContactLocalId in Qt5

Mathias Hasselmann mathias at openismus.com
Tue Nov 1 14:56:52 CET 2011


Am Dienstag, den 01.11.2011, 14:05 +0100 schrieb Mathias Hasselmann:
> Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell:
> > Hi Paivi,
> > 
> > > 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.
> 

Short IRC discussion with Robin revealed the idea to me.

You want permit the backend itself define what a local id looks like. So
you propose an even more sophisticated variant of my QVariant propose.
Also fine with me. Hard part will be defining a proper API that avoids
accidential round trips between native format and string (or QVariant)
representation.

Also the documenation of such a class should be very explicit about
memory consumption, performance and such. Maybe even a few default
implementations demonstrating best practice should be provided.

Ciao,
Mathias
-- 
Mathias Hasselmann <mathias at openismus.com>
http://openismus.com/




More information about the Development mailing list