https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #4 from Tobias Mueller <[email protected]> --- (In reply to comment #3) > In other words, add a setup wizard mode to the command line. That's doable, > but also quite a bit of work. > Hm. Maybe not exactly a wizard with steps and all. But in the case of CalDAV or CardDAV, it should be possible to check the remote contents for being either calendar, todolist or addressbook data, I think. > Did the terminology section help? It should have. If not, I need to reword > it. > Hm. I don't know. It's just so much text. Every time I read it, I feel it's totally clear. But shortly after that, when trying to interact with SyncEvolution, that feeling is gone and total confusion and frustration kicks in. Many things seem to be implicit and it's not immediately clear what the things are, that I give a name, i.e. "target-config@radicale", "calendar1", "radicale". And if anything goes wrong, the sanest thing to do seems to be to mv ~/.config/syncevolution out of the way, because I find it not discoverable which part failed due to which configuration (and how to change it then). That also adds to the frustration. I'm just ranting here without any proposal at all. Shame on me. But despite my really unimportant frustration, I do appreciate all your efforts and I am grateful that you really try to make syncing happen (it's 2012 after all...). Anyway, maybe a picture would help. For various use cases. For me, I would probably appreciate a picture with PC, a "cloud", several databases and the relevant terms attached to them. > > I do get empty vcards, however. > > The output of > SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export - > target-config@radicale cards1 > > would be useful. > $ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items target-config@radicale cards1 [DEBUG 00:00:00] Wed 2012-10-24 10:32:09 UTC = 12:32 +0200 CEST [DEBUG 00:00:00] using libneon neon 0.29.6: Library build, IPv6, Expat 2.0.1, zlib 1.2.5, GNU TLS 2.12.14. with SSL, ZLIB, IPV6, TS_SSL, I18N HTTP session to http://${URL}:80 begins. sess: libproxy #0=direct:// [DEBUG 00:00:00] cards1: slow sync or testing, do full item scan to detect changes [DEBUG 00:00:00] starting PROPFIND, credentials unverified, deadline in 300.0s ah_create, for WWW-Authenticate Running pre_send hooks [DEBUG 00:00:00] forced sending credentials Sending request headers: PROPFIND /muelli/cards/ HTTP/1.1 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Host: ${URL} Depth: 1 Content-Length: 141 Content-Type: application/xml Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sending request-line and headers: Doing DNS lookup on ${URL}... req: Connecting to ip.ip.ip.ip:80 Sending request body: Body block (141 bytes): [<?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><prop> <getetag xmlns="DAV:"/> <resourcetype xmlns="DAV:"/> </prop></propfind> ] Request sent; retry is 0. [status-line] < HTTP/1.1 207 Unknown [hdr] Date: Wed, 24 Oct 2012 10:32:09 GMT Header Name: [date], Value: [Wed, 24 Oct 2012 10:32:09 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] DAV: 1, 2, 3, calendar-access, addressbook, extended-mkcol Header Name: [dav], Value: [1, 2, 3, calendar-access, addressbook, extended-mkcol] [hdr] Content-Length: 2289 Header Name: [content-length], Value: [2289] [hdr] Keep-Alive: timeout=15, max=100 Header Name: [keep-alive], Value: [timeout=15, max=100] [hdr] Connection: Keep-Alive Header Name: [connection], Value: [Keep-Alive] [hdr] Content-Type: text/xml Header Name: [content-type], Value: [text/xml] [hdr] End of headers. Running post_headers hooks Reading 2289 bytes of response body. Got 1160 bytes. Read block (1160 bytes): [<?xml version="1.0"?> <multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <response> <href>/muelli/cards/</href> <propstat> <prop> <getetag>"-7768052930791486994"</getetag> <resourcetype> <C:calendar /> <collection /> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf</href> <propstat> <prop> <getetag>"6142677616598662413"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/13fc9240-91c7-4644-95e1-033729e236cb.vcf</href> <propstat> <prop> <getetag>"-793186154807718785"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf</href> <propstat> <prop> <getetag>"-7419273146883220427"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200] [DEBUG 00:00:00] item 3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf = rev 6142677616598662413 [DEBUG 00:00:00] item 13fc9240-91c7-4644-95e1-033729e236cb.vcf = rev -793186154807718785 Reading 1129 bytes of response body. Got 1129 bytes. Read block (1129 bytes): [ OK</status> </propstat> </response> <response> <href>/muelli/cards/342F8BEA-54AC0772-04A3D2F6.vcf</href> <propstat> <prop> <getetag>"6187965458013749004"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/1e91aa4d-11ca-4580-bc35-2ba170338837.vcf</href> <propstat> <prop> <getetag>"6030810582171879567"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf</href> <propstat> <prop> <getetag>"-6196304151567771931"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/muelli/cards/72e42321-92d7-4197-b150-1ee77a370645.vcf</href> <propstat> <prop> <getetag>"3294707919730409193"</getetag> <resourcetype /> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> ] [DEBUG 00:00:00] item 1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf = rev -7419273146883220427 [DEBUG 00:00:00] item 342F8BEA-54AC0772-04A3D2F6.vcf = rev 6187965458013749004 [DEBUG 00:00:00] item 1e91aa4d-11ca-4580-bc35-2ba170338837.vcf = rev 6030810582171879567 [DEBUG 00:00:00] item 2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf = rev -6196304151567771931 [DEBUG 00:00:00] item 72e42321-92d7-4197-b150-1ee77a370645.vcf = rev 3294707919730409193 Running post_send hooks ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none) Request ends, status 207 class 2xx, error line: 207 Unknown [DEBUG 00:00:00] credentials accepted Running destroy hooks. Request ends. 13fc9240-91c7-4644-95e1-033729e236cb%2evcf 1e91aa4d-11ca-4580-bc35-2ba170338837%2evcf 1ec200d5-735b-4d16-a0cd-0bcfb0923fa4%2evcf 2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac%2evcf 342F8BEA-54AC0772-04A3D2F6%2evcf 3c59174f-d09b-43aa-9eee-26f3740c0ac7%2evcf 72e42321-92d7-4197-b150-1ee77a370645%2evcf sess: Destroying session. > On the server side, I hav e the following in > > the collection: > > > > BEGIN:VCALENDAR > > PRODID:-//Radicale//NONSGML Radicale Server//EN > > VERSION:2.0 > > BEGIN:VCARD > > That looks suspicious. Normally VCARDs are not stored inside VCALENDAR. > uh. interesting. Maybe a radicale bug. Apparently, it's not a very nice Ca{rd,l}DAV server as it doesn't care about standards so much (besides it being *very* slow with a couple of hundred items). But it still seems to be nicest server out there :-\ -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
