Implement QContactCollection API
The latest QtPim brings in a "collection" API, whose support is mandatory: the contacts model now operates first by listing collections, then listing contacts on each collection. If the new
QContactCollectionFetchRequest request is not handled, the model will appear empty.
I've had a mail exchange with Chris Adams, and I'm reporting here the relevant parts:
> I'm planning to create a Collections table, with the standard fields for > QtCollection's details and a BLOB for the extended metadata. I'm > wondering if I should create a couple of additional fields for the > "syncTarget" and for the online account (in case the collection is bound > to a sync target or to an online account). Though it's not clear to me > how these things are currently built (for instance, I would expect to > see a "syncTarget" field) in the online accounts table, but it's not there. Right, I think there are probably three "standard" metadata fields, which probably deserve their own fields in the collections table: 1) the "owner" sync plugin (e.g. the name of the plugin which is responsible for syncing this addresbook). This is effectively the old "sync target" value, I guess. 2) remote endpoint url (e.g. the addressbook path url if it's a remote carddav addressbook). This will be non-empty if it's a remote addressbook which should be synced, but will be empty if it is a local addressbook. If it is non-empty, the consumer is the sync plugin which should sync that addressbook. 3) the sync anchor (consisting of two pieces of data: the last sync timestamp, and optionally the sync token string/url, which is the token from the last time the addressbook was synced. By providing this to the carddav server, you get all changes which occurred server-side since the last sync. Not all servers support sync tokens, so in that case the sync plugin would need to do a manual "get me all changes since the specified date-time" style sync, but this is error prone due to timestamp accuracy, races, etc). Regarding the online-accounts table, you can basically ignore that one, I think - it's just a contact detail (that is, let's say I have a contact John Smith, he might have an OnlineAccount detail associated with him like: firstname.lastname@example.org, which has some meaning to some application). Sync targets are separate/not really related to those details (although, potentially, you might sync an entire addressbook of contacts from social.net using your own account credentials if you had such a sync adapter etc). > And would it be correct if I remove the syncTarget field from the > Contacts table, once we have it in the Collections one? Yes, I believe so. -- One other major change is that currently, the backend allows writes to the "aggregate" contact, and then it attempts to figure out the provenance (e.g. sync target, constituent contact) of the detail which was edited (or, if a detail was added, I think it chooses to edit the "local" addressbook constituent contact). BUT going forward, with "proper" collection support, I would like to change it so that the aggregate contact MUST BE read-only. That is, any change must be made specifically to a constituent contact (i.e. in a collection; either the local phonebook collection if the user edited some detail manually, or some remote-synced collection i.e. the change is due to a sync). Then, instead of doing the complex "down-promote" stuff, we instead only do "up-promotion" (i.e. generating the aggregate from the constituent details). This also simplifies the synchronisation helper code (twowaycontactsyncadapter.cpp etc) since we should in future only upsync the specific per-sync-target collection constituent contact details to the remote server, rather than what it does at the moment (which is very wrong: it calculates some heuristically-determined combination of the local-constituent+sync-target-constituent details, and syncs those...).