William,
Thanks a lot for these examples of configuring syncevolution with
multiple sources! I'd say it's not trivial (at least for me) based on
the manual page on syncevolution...
Regards,
Vlad.
----- Message from William Kenworthy <[email protected]> ---------
Date: Thu, 16 Feb 2012 19:54:01 +0800
From: William Kenworthy <[email protected]>
Subject: Re: [SyncEvolution] syncevolution and a radicale caldev server
To: syncevolution <[email protected]>
On Tue, 2012-02-14 at 15:57 +0100, Patrick Ohly wrote:
On Tue, 2012-02-14 at 21:36 +0800, William Kenworthy wrote:
> Now partly working! I deleted the contents of .config/syncevolution/
> and got a different error. I then re-edited the file with the config
> lines to remove tabs and just leave spaces and also deleted the database
> entry as its in the config files ... and its now working. Its possible
> that all the cutting and pasting from web pages and documents allowed
> some non-printing characters in somewhere - perhaps config file
> sanitation needs improving?
If can give me a specific example, then I might be able to do something.
But without more hints I don't know what I might have to do differently.
> But I have 4 calendars on the radical server and the config below placed
> them all in the one n900 set as default - is it possible to get them
> into the proper calendar on the n900? Replacing the word "Test" with
> another Calendar name such as "Bill" doesnt work - still went to
> default.
The name that you use for your @Test context doesn't mean anything to
SyncEvolution. A better name in your case would be @radical or even
better, the specific name of the machine hosting that instance (in case
that you ever have more than one installation).
> The database entry in the config files suggests it should have
> worked :( I have seen this commented on in other posts but the fix
> (copying/deleting files was for an older revision of syncevolution and
> it didnt seem to apply here.)
It shouldn't ever have been necessary to copy config files.
> For the documentation I suggest examples tagged (comment) with the
> version of syncevolution they apply to. Much of my initial confusion
> stemmed from seeing examples on the web that people are supposedly using
> that didn't work for me.
But wouldn't these tags have to go into these example on the web? I
don't have any control over those.
http://syncevolution.org/documentation/syncevolution-usage has exactly
such a tag at the top.
> I think the best approach would be to extend
> you have done with the google examples - complete, working examples. My
> final one here could be suggested for "Radicale"
The problem is that I cannot do that for all possible peers. There are
way to many of them. At some point users have to be able to adapt some
example to their own case.
But as Radicale is an example where multiple databases are possible (in
contrast to Google), it's worth spelling out explicitly how such a
config can be created:
# create config for accessing the CalDAV server
$ syncevolution --configure \
--template webdav \
username=zzz \
password=zz \
syncURL="http://moriah.lan.localdomain:5232/"; \
target-config@radicale
# list databases (only works in syncevolution >= 1.3, not released yet)
$ syncevolution --print-databases target-config@radicale calendar
target-config@radicale/calendar:
zzz zz (http://moriah.lan.localdomain:5232/zzz/Test/) <default>
Second Calendar (http://moriah.lan.localdomain:5232/zzz/Test2)
# Configure @radicale context so that provides access to both
# calendars; repeat if you have more than two.
# Mind the trailing slash in the database URL, it is required in 1.2.x!
$ syncevolution --configure \
database=http://moriah.lan.localdomain:5232/zzz/Test/ \
backend=caldav \
target-config@radicale calendar
$ syncevolution --configure \
database=http://moriah.lan.localdomain:5232/zzz/Test2/ \
backend=caldav \
target-config@radicale calendar2
# check access to Racicale server
$ syncevolution --print-items target-config@radicale calendar
...
$ syncevolution --print-items target-config@radicale calendar2
...
# list local databases (when using syncevolution < 1.3)
$ syncevolution
...
# list local calendars (when using syncevolution >= 1.3);
# in this case, backend=calendar uses Evolution Data Server
$ src/syncevolution --daemon=no --print-databases backend=calendar
calendar:
Personal (local:system) <default>
SyncEvolution_Test (local:1237386992.13712.0@pohly-MOBL)
# Set up syncing of the who local database with the two databases in
# the Radicale server. The EDS backend can select databases both
# via name and URI.
$ syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://@radicale \
username= \
password= \
calendar/database=local:system \
calendar/uri=calendar \
calendar/backend=calendar \
calendar/sync=two-way \
calendar2/database=SyncEvolution_Test \
calendar2/uri=calendar2 \
calendar2/backend=calendar \
calendar2/sync=two-way \
radicale \
calendar calendar2
# check access to local calendar
$ syncevolution --print-items radicale calendar
...
$ syncevolution --print-items radicale calendar2
...
# synchronize for the first time
$ syncevolution --sync slow radicale
...
# incremental sync
$ syncevolution radicale
...
Note that this is for a desktop installation where "backend=calendar"
resolves to the EDS calendar backend. I don't know whether the N900
calendar backend also supports multiple local calendars. Your question
above implies that at least the N900 does.
> Lastly there is the problem with tabs and spaces in the config file - I
> am not sure if this is real and a bug or not.
Can you be specific about this?
> I have also noticed that
> the config files created by syncevolution for "Test" are
> in .config/syncevolution/test (lower case "T") - another source of
> confusion for me.
There is some normalization of the config names. The full name as chosen
by a user and shown to it again later in the UI is stored in a property,
whereas the file name is simplified to avoid generating invalid file
names. Arguably we could avoided lower-casing as part of normalizing the
name, but it made seemed to make sense at the time.
Thanks Patrick its now working in a usable fashion. I actually have 8
addressbooks for things like family members, work etc. (had! - lost the
lot when experimenting, my fault :(
I do have to use "--sync refresh-from-client" as any kind of two way
sync including slow fails with 401 and 409 errors. The radicale log
shows that if I try and send any changed data from the n900 to radicale,
it fails as the path is not attached: a good transaction includes
something like "/zzz/Dan/1291.ics" while one that fails has
syncevolution passing "/1291.ics" to radicale which fails the auth
checks (gets mapped to user noboddy)
But even one way sync is better than what I had before!
BillK
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
----- End message from William Kenworthy <[email protected]> -----
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
