Hi kschultz, thanks for that feedback.
You're right, solution (2) allows the specific manager to build the id manually. We have prototyped up a (mostly complete, but untested; prototype) version of this API, available at:
http://qt.gitorious.org/qt-mobility/contacts/trees/multical-custom/src/organizer
Especially, see the qorganizeritem.h/cpp, qorganizeritemenginelocalid.h/cpp, and for an example implementation, the engines/qorganizeritemmemorybackend.cpp/_p.h.
Solution (4) with quint64 was investigated more thoroughly, and it doesn't seem to provide any advantages over the quint32 version if the nativeId could possibly be a string (that is, on those platforms, a full database read is required to build up the mapping on instantiation or on first read), so this solution is not optimal.
Solution (5) is nice, but apart from the memory-usage, there is the added problem that whenever the engine receives on of these, it must parse the string to break out the bits that it needs, serially, for every id in the list (eg for a fetch request taking a list of ids). This cost seems prohibitive, since it affects (pretty much) every operation.
So, we think you're right -- solution (2) seems the nicest. If you (or anyone else) do (does) get a chance to review the proposed API, that'd be greatly appreciated.
Cheers,
Chris.
edit: there's currently one major missing piece of functionality from that branch: converting to/from a QVariant isn't implemented (needs to serialize/deserialize the private implementation in that conversion process). Just to be clear, it IS implementable (although may have to instantiate the engine factory and request the deserialization during the process..) but just not implemented yet.
