Hello again, I've added a stupid filter that should do the trick: https://github.com/Kozea/Radicale/commit/25c3648d7536ce37e95329f59e1dcd1afc25c632
I've only tested the code with curl, not with SyncEvolution. If anything goes wrong (or if it works, of course), please let me know! Regards, -- Guillaume Le lundi 11 juin 2012 à 18:55 +0200, Patrick Ohly a écrit : > 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> > ] >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
