On Sat, 2012-06-09 at 10:24 +1200, Jane Atkinson wrote:
> On 08/06/12 23:56, Patrick Ohly wrote:
> > On Fri, 2012-06-08 at 01:57 +1200, Jane Atkinson wrote:
> >> One other question: how do I activate memo sync?
> >
> > That's blocked by a know missing feature:
> > https://bugs.meego.com/show_bug.cgi?id=24893
> >
> > I left that as a low hanging fruit for some new developer who wants
> > to pick up some easy task, but no such developer has materialized
> > yet. I guess it is important enough to work on myself before
> > releasing 1.3.
> >
> > Which server are you using which supports VTODO?
> >
>
> I'm using Radicale 0.7 It supports VEVENT, VTODO and VJOURNAL through EDS.
>
> So, are some of these types not available as a direct CalDAV sync? I
> might need to rethink rearranging my system if that's the case.
They are not available yet, but I have already added much of the
necessary code and started testing it today against Radicale.
How are you using Radicale? Do you put all three item types into the
same collection (= URL), or do you maintain separate ones?
Radicale supports the former, but it has a bug (or missing feature,
depending on how you look at it): when asked to filter items in a REPORT
by data type, it returns items of the wrong type. Below is an example
(asked for VEVENT, reports VTODO).
In comparison, Apple Calendar Server does honor the filter as I expect.
Guillaume, what do you think? Is this a bug and can it be fixed?
This makes it hard for SyncEvolution to synchronize just the items of
the right type if they are mixed in the same collection. It basically
has to download *all* items, including their data, to verify by parsing
the data what each item really is. If it doesn't do that and the server
is returning wrong results, SyncEvolution may end up deleting unrelated
items => data loss.
Because the backends for events, todos, and journals are conceptually
independent, this has to be done three times for each collection.
Arguably it would be more efficient to only query a collection once per
sync, but as long the query can be limited to just reading the meta
data, I'd rather not introduce hacks which break the SyncEvolution
architecture.
Sending request headers:
REPORT /public_user/calendar/calendar_1/ HTTP/1.1
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
Host: 127.0.0.1:5232
Content-Length: 305
Depth: 1
Content-Type: application/xml; charset="utf-8"
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxx
Sending request-line and headers:
Doing DNS lookup on 127.0.0.1...
req: Connecting to 127.0.0.1:5232
Sending request body:
Body block (305 bytes):
[<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
<C:calendar-data/>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>
]
Request sent; retry is 0.
...
Read block (3240 bytes):
[<?xml version="1.0"?>
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<response>
<href>/public_user/calendar/calendar_1/00d8be00-8654-4d29-81c3-43331b9737ed</href>
<propstat>
<prop>
<getetag>"1141198603189936281"</getetag>
<C:calendar-data>BEGIN:VCALENDAR
PRODID:-//Radicale//NONSGML Radicale Server//EN
VERSION:2.0
BEGIN:VTIMEZONE
[multiple time zone definitions]
END:VTIMEZONE
BEGIN:VTODO
UID:20090401T145153Z-22321-1000-1-18@pohly-MOBL
DTSTAMP:20090401T145153Z
SUMMARY:test task with plenty of fields
...
END:VTODO
END:VCALENDAR
</C:calendar-data>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
]
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
