[Development] QContactLocalId in Qt5

[cristiano.di-flora at nokia.com]

Hi all,

First of all, I'd like to say that especially with my QtContacts
maintainer hat, this discussion is very very interesting, and I am really
happy to see it happening already after a few days from the kick-off of
the qtproject initiative :)

Now, back to business....just had a chat on IRC with Chris, and I decided
to loop him and michael into this thread explicitly.
Chris has described quite well where the pattern currently used in
organizer stemmed from.
The decision taken in the old mobility times is partially documented here:

http://developer.qt.nokia.com/forums/viewthread/363/

Based on that thread, Chris, Michael, and their team decided to adopt the
pattern we nowadays see in Organizer.
Chris' comments suggested that same pattern should be adopted in Contacts
as well, so as to make the QtPim APIs consistent and, at the same time,
improve the current situation in QtContacts, which we all agree is
sub-optimal.
To summarize, we have these options on the table:
1. Keep the QString based approach and align Organizer to it
2. Keep the Organizer approach and start using the same design pattern in
QtContacts
3. Move all APIs to use QByteArray
4. Move all APIs to use QVariant

It seems everybody agrees that Option 1 is a no-go.

Similarly, we seem to have some concerns with option 4, since it brings to
similar issues of option 1 even though it is slightly more flexible.


Option 2 provides a good trade-off between flexibility and performance.
Option 3 might be beneficial in terms of performance, but I would also
like to see more evidence about this, like for example some results of
benchmarks / performance tests that can really show the gap between 2. And
3. Would be also good to understand better the impact of that change on
engine's side as well as on the client APIs.

So now would be the moment to take a decision, and I invite everybody to
make his/her concerns about those options crystal clear.
Based on the feedback we got so far from different experts in this
discussion thread, my current understanding as QtContacts maintainer is
that I would go for option 2, with the possibility for some changes /
adaptations based on the answers / comments you will send here.
Other proposals are definitely welcome in this phase, as well as
additional solutions not included in the 1-2-3-4 options above. Whatever
the final decision will be, I hope we can take it as soon as possible and
start doing the implementation work and have more fun ;) I would be happy
if this would happen in one week from now....and increasingly happier if
we can decide before one week time :)

I hope Michael and/or Chris can help us to take the right decision as
well, based on their experience with benchmarking different options in the
past Mobility life of these APIs.

I look forward to receiving comments, suggestions, and votes/preferences
in the next days.
Ciao!
-Cristiano

________________________________________
Cristiano di Flora, PhD

SW Architect / Technical lead

Nokia - Qt Software development

Visiokatu 3
33720, Tampere (FINLAND)

________________________________________




On 11/1/11 3:56 PM, "ext Mathias Hasselmann" <mathias at openismus.com> wrote:

>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/qorganizerite
>>mengineid.h and
>> > > 
>>http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizerite
>>mid.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/
>