Hi, I was trying to set up syncevolution to work using akonadi. Following the howtos I built a static binary. syncevolution --print-databases shows useful entries for kde-contacts, kde- calendar, and kde-memos. However the kde-task list isn't showing a useful resource.

I used akonadiconsole to verify that there is a task folder (hosted via kolab) whose identifer is 375. I can use --print-items to get a list of ids from @default calendar, but the task list is empty. Was wondering if the task list is supposed to be working?

> > I used akonadiconsole to verify that there is a task folder (hosted via > > kolab) whose identifer is 375. > > > > I can use --print-items to get a list of ids from @default calendar, but > > the task list is empty. > > > > Was wondering if the task list is supposed to be working? > > SyncEvolution supports task lists which store items in the > "text/calendar" = iCalendar 2.0 format, because that is what > SyncEvolution reads and writes. What content format does the missing > task folder have? I looked using akonadiconsole and the mime type of the folder is: application/x-vnd.akonadi.calendar.todo I made the following change and the todos showed up with --print-databases / --print-items

> Accessing items with --print-items/import/export/update/delete-items > will work, because that passes the item content through unmodified. > > However, syncing will not work because it needs to convert between the > format used by the storage and the internal representation ("field > list"). > > What does this application/x-vnd.akonadi.calendar.todo format look like? > Are there KDE utility classes for parsing and generating it? > > And finally, do you think you could add support for this format, with > some help of course? I can try. The file looks mostly like [iv]Cal.

I made a couple of test todos and did "syncevolution --export - @default todo", loaded the result into vi and pasted into the email. (nicely demonstrating the inconsistent eol marks).

The KDE Pim tools support hierarchical todos which seemed like an uncommon feature. I'm not sure if RELATED-TO: is a non-standard attribute.

> Right. I wonder what the difference is, because I fail to see one in the > quoted examples. Handling those extensions while syncing can become > tricky. If they cannot be mapped to iCalendar 2.0, then at least the > Synthesis field list and Synthesis profile for iCalendar 2.0 should > support them, because otherwise the extensions will get lost when > updating an item in Akonadi. > > For the iCalendar 2.0 subset, syncing should already work with your > patch. If there are Akonadi resources using "text/calendar" with VTODO, > then a better solution would be to search for both by expanding the > parameter given to the AkonadiSyncSource from a single-value string to a > list. So after the tiny patch I made todos seem to have synced correctly. I went looking through the kdepimlibs source code to see if I could understand why they're using the x-vnd mime type. Ok I got a reference from #akonadi. They used the different mime types to "differentiate between events, journals and todo entries; there's a different mime type for each and text/calendar is a bit vague." "Externally those are all ot be treated as text/calendar". Through the freedesktop shared-mime-info system they declared the application/x-vnd.akonadi types as subtypes of the standard text/calendar type.