On Fr, 2011-08-19 at 18:50 +1000, Roger KeIrad wrote: So the goal is to make it work with GPE? In that case you have to ask yourself first whether reading/writing the sqlite database directly really is the right approach. If GPE has a library accessing it, then most likely that is the official API. Bypassing it will lead to maintenance/compatibility problems if that schema changes. You also have to duplicate existing work (mapping from some higher-level representation of calendar data to the schema). If you decide to use such a library and it has some iCalendar import/export mechanism, then you can use some of the existing backends as example to copy and adapt, for example the KCalExtended backend. If it does not have such import/export, then an approach as in the SQLiteContactSource with copying data from Synthesis directly (see readItemAsKey/insertItemAsKey) may be easier. If you want to use the Synthesis sqlite support, then you are entering new ground. SyncEvolution has never used this before, so you would have to figure out how to integrate that first. You'll have to understand what needs to be in the Synthesis XML config (run with loglevel=5 to see it) for an sqlite-based datastore. In SyncEvolution, that part of the config is created by SyncSourceBase::getDatastoreXML(). You'll have to modify the SynthesisInfo structure such that your SyncEvolution backend can tell the core SyncSourceBase class a) that the backend wants to use sqlite and b) with which parameters. Change tracking could be done based on the ID + "modified" field. See SQLiteContactSource + listAllItems(). You'll need to know exactly what the semantic of these fields is and how they map to the Synthesis fields. For example, what are valid values for the recur integer? What is the difference between uid and eventid? -- 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.