Hi Patrick, I imagine that Michael will want to respond more fully in this thread in the near future, but I'll try to answer some of your questions below.
>-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of ext Patrick Ohly >Subject: [MeeGo-dev] data storage and indexing in MeeGo - a survey > >Hello! [snip] >Contacts >======== > [snip] > >QVersit: >incomplete (?) subset of QContact The versit module tries to provide complete (and round-trip-stable) conversion between a QContact and a vCard. However, different backends can have their own definitions/schema for data, and so the versit modules provides hooks to allow synchronization agents to do their own mapping for specified data types / fields. >Question: there used to be documentation in QVersit about the mapping >between vCard and QContact. Last time I looked, I only found that in the >Google cache. Is that documentation still maintained somewhere? http://doc.qt.nokia.com/qtmobility-1.1-tp/vcardsupport.html#vcardsupport Lists the default mapping. > >Question: can someone provide an example of a full-featured contact (as >many QContact details set as possible, including custom details) and how >that is stored in Tracker and a vCard? > > >Calendar >======== > >QtMobility Calendar: >unique ID under debate, see >http://developer.qt.nokia.com/forums/viewthread/363/ It's been decided to allow the engine to provide their own custom id type, in the Qt Mobility Organizer API. The problem arose from the way in which items could be uniquely referenced by clients; on some platforms this requires extra information than just the event-id (for example, the filename of the calendar file in which it is stored, the notebook name, the datastore name, etc etc). Having a custom engine id allows backends to define their own id format, which should be more performant and more extensible. > >mkcal: >combination of UID + RECURRENCE-ID (optional) + calendar file, >change notification only via coarse "calendar has changed" in >SqLiteStorage, >time zone changes from timed > >Tracker: >NEPOMUK Calendar Ontology (NCAL), >pushed by mkcal Sqlite storage, >only ncal:uid seems to be set, RECURRENCE-ID is mangled into item ID, >detailed changes via >SopranoLive::BackEnds::Tracker::ClassUpdateSignaler? > >See http://meego.gitorious.com/meego- >middleware/mkcal/blobs/master/src/trackermodify.cpp > >Question: serializing a RECURRENCE-ID into a single string is hard >because it is a DATE-TIME value + TZID (iCalendar 2.0) resp. a KDateTime >(mkcal). What is the recommended way of serializing it? > >It seems that RECURRENCE-ID is stored in Tracker, but only after >conversion to UTC and without milliseconds: >// The format supported by tracker is not really ISO8601, as it >// doesn't support milliseconds. Therefore we eliminate those here. >QString kdatetime2String( KDateTime dt, bool toUtc=true ) > >Question: ignoring the problem with milliseconds here (doesn't matter >for iCalendar 2.0), can mkcal find the original incidence when it has a >RECURRENCE-ID using a time zone and the query uses UTC? Timezones are a very important issue which we need to address soon. Discussion is ongoing as to how timezone support will be offered in the Qt Mobility Organizer API. Cheers, Chris. >-- >Best Regards, Patrick Ohly > >The content of this message is my personal opinion only and although >I am an employee of Intel, the statements I make here in no way >represent Intel's position on the issue, nor am I authorized to speak >on behalf of Intel on this matter. > > >_______________________________________________ >MeeGo-dev mailing list >[email protected] >http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
