[Development] QContactLocalId in Qt5

[christopher.adams at nokia.com]

Hi,

Regarding QContactLocalId in particular, I personally think doing something like QOrganizerItemId makes the most sense, but more benchmarking and prototyping is required before anyone could say for sure, I guess.  Matthias and Robin have mentioned (on IRC) some performance considerations which will need to be kept in mind, but in general I think it's a good idea to allow the backend to use the most optimal format it can, and I think having an opaque datatype is fine for an id.

Further comments inline:

> Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell:
> > 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.

[CA] In my opinion, it's definitely a good idea to make improvements to the PIM APIs for Qt5 where possible; but of course, the scope of the changes needs to be managed carefully.

> 
> QLatin1Constant
> 
> If that one is to be kept, then QLatin1Constant::operator QString() should go
> and only the QLatin1String() variant should be left. Often enough C++ fails to
> choose between the QString() and the QLatin1String() variant, causing us to
> write ugly things of this kind:
> 
>    foo = baz.operator QString()

[CA] Wasn't there discussion about introducing something like this into Qt5 base (ie, readonly, shareable, constant string data with fast comparison)?  If so, it might be possible to remove this from the PIM module entirely.

> 
> QContactStringHolder
> 
> It creates long living objects causing heap fragmentation. For qtcontacts-
> tracker we got bug reports for wasting dirty pages worth several mega bytes
> because of this. To avoid that fragmentation, QContactStringHolder should
> be made public, so that engines can warm the cache, or even better that
> code should be change to use some better memory allocator. Slab, like
> successfully used by GSlice would be an option. Adrien has more details.

[CA] Yes, have to be careful about how this is done.  Obviously it would need to retain the super-fast (pointer) comparison, but the way it caches QStrings could be improved (even if it is just to provide hooks to engine implementers, to allow clearing stale entries or warming the cache on init, etc).  I'm sure there'll be some complexities associated with any implementation change touching this.  Adrien, did you have anything in particular in mind for this case?

Aside from these issues, some other possibilities for changes that have been raised before include:
a) have a ChangeListener or Observer class which reports change notifications to clients, instead of emitting directly from the manager, allowing filtering etc.
b) ways we could make the Manager classes usable as a model (or an easy way to get a model from a manager, with signals already hooked up etc)
c) asynchronous API modifications: removing the waitFor functions, perhaps considering splitting into request/response?
d) slimming down the synchronous API in Manager classes.  How many of those functions are needed?  Certainly many of the detail definition mutation functions are probably superfluous.  Some of the manager features aren't well defined (eg, group support), and I wonder how useful run-time querying of manager capabilities is, anyway...
e) possible areas for closer alignment between the organizer and contacts APIs.
f) detail linking and cross-domain item linking (standardized uri format / generation, etc)
g) ... etc

Of course, making too many changes would be counterproductive, especially if there's no clear use-case for, or benefit derived from, the changes; I mention them just to provide a possible starting point for further discussion.  I look forward to seeing the list of improvements and ideas which Paivi mentioned, too.

Cheers,
Chris.