[Syncevolution-issues] [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|syncevolution-issues@syncev |patrick.ohly(a)gmx.de
|olution.org |
--- Comment #3 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #2)
(In reply to comment #1)
> I'm open for suggestions how this could be made simpler. There's a mail
> thread about that here:
> http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
>
Thanks for the hint. And thanks for working on that!
In my dream, it only asks me about the type of data to be synced and the
remote and local storage, i.e.
--calendar --local evolution:Personal --remote
caldav://foo:bar@baz/user/storage/
or so.
Or better yet, it would auto detect that I have calendar data remotely and
select that.
In other words, add a setup wizard mode to the command line. That's doable, but
also quite a bit of work.
> > $ syncevolution --daemon=no target-config@radicale cards1
>
> You are trying to sync with the "target config". Syncing must be
triggered
> via the "sync" config.
oh. wow. That's all double dutch to me :-\ I read the explanation on the
website though. A couple of times. It's just mind blowingly much information.
Did the terminology section help? It should have. If not, I need to reword it.
I probably could have gotten suspicious by this line:
> [DEVELOPER 00:00:00] SyncML server account: user1
But then again, that line also appears in other logs (just without the
username)
It probably would make sense to add more explicit INFO lines about what
SyncEvolution is doing. Before 1.3, such output would have been mixed with
normal output (for example, the item content in --export -), therefore
SyncEvolution was very quiet. Since 1.3, such messages go to stderr and can be
used more liberally. It's just again something that has been done yet.
I do get empty vcards, however.
The output of
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
target-config@radicale cards1
would be useful.
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.
> Oh, I see: the very first time a source is used it goes through
yet another
> code path. The downside of trying to minimize requests - many special cases
> :-(
So shall this bug be about tracking that crasher, then?
That, and the empty vCard issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Attachments:
- attachment.html (text/html — 4.7 KB)