Re: [SyncEvolution] syncevolution and a radicale caldev server

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 SyncEvolution(a)syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution