-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/06/12 03:52, Patrick Ohly wrote: > On Sun, 2012-06-17 at 14:40 +0200, Patrick Ohly wrote: >> On Sun, 2012-06-17 at 14:30 +1200, Jane Atkinson wrote: >>> On 17/06/12 00:19, Patrick Ohly wrote: >>>> >>>> 1.2.99+20120615+SE+1c2f1c2+SYSYNC+de54721 is released as >>>> unstable version and has support for VTODO and VJOURNAL. >>>> >>>> commit 5bc01e79901ade98269ee9a244f52f9544ec13b1 Author: >>>> Patrick Ohly <[email protected]> Date: Tue Jun 12 >>>> 17:41:46 2012 +0200 >>>> >>>> CalDAV: support VJOURNAL + VTODO (BMC #24893) >>>> >>>> The new backend property values "CalDAVTodo" and >>>> "CalDAVJournal" select tasks resp. memos stored in a CalDAV >>>> collection. "CalDAV" continues to select events. >>>> >>>> Events, tasks and journals can be mixed in the same resource >>>> (= URL). However, this is less efficient than storing them >>>> separately. >>>> >>>> A good CalDAV server allows filtering items by type, and >>>> SyncEvolution uses that. However, it was found that Radicale >>>> 0.7 ignores this filtering, which could have led to data >>>> loss (SyncEvolution asks for all VTODOs in preparation for a >>>> "delete all items" operation in a "CalDAVTodo" source, gets >>>> also VJOURNALs, then deletes them). >>>> >>>> Therefore SyncEvolution plays it safe and downloads the VTODO >>>> and VJOURNAL data to double-check that it is working on the >>>> right items. This causes additional traffic for well-behaving >>>> servers; currently it cannot be turned off. >>>> >>>> What is missing for VJOURNAL is the conversion to plain text >>>> (see BMC not possible yet. >>>> >>>> You use this by replacing "backend=caldav" with >>>> "backend=caldavtodo" resp. "backend=caldavjournal" when >>>> configuring "todo" resp. "memo" sources. >>>> >>> >>> >>> Having got rather confused over the command line configuration >>> (trying to add the additional capabilities), I decided to >>> delete the entire @webdav config altogether and start again. >>> >>> I began with: syncevolution --configure \ --template webdav \ >>> username=name \ "password=" \ syncURL=http://servername:5232/ >>> \ target-config@webdav >>> >>> which just hung and did nothing. >> >> Indeed it looks like it does nothing. I had to run with >> additional debug output enabled to figure it out. >> >> In my case, with literally using "servername" in the syncURL, it >> hangs because the command tries to verify that there is a valid >> collection for the "addressbook" source. It does that to enable >> only those sources in the webdav template which really work. >> >> Because the host name lookup fails and that is considered a >> temporary problem (well, it might be...), it retries for several >> minutes. >> >> The logic comes from a time when database lookup was local, quick >> and didn't fail. I wonder whether it still applies, and how the >> process can be made more transparent to the user. I guess an INFO >> message when starting to look for databases would at least give a >> hint. > > Now there is more output. It currently looks like this: > > $ ./syncevolution --configure --template webdav \ > syncURL=http://192.168.1.100:9000/ \ username=foo password=bar > retryDuration=2s \ target-config@webdav-temp [INFO] creating > configuration target-config@webdav-temp [INFO] addressbook: looking > for databases... [INFO] addressbook: no database to synchronize > [INFO] calendar: looking for databases... [INFO] calendar: no > database to synchronize [INFO] memo: looking for databases... > [INFO] memo: no database to synchronize [INFO] todo: looking for > databases... [INFO] todo: no database to synchronize > > It timed out fairly quickly here because of the retryDuration=2s. > That also gets placed in the resulting config, which is probably > not desired. Does this output give enough hints for the user to > recognize that there is an issue with the syncURL or the server > when it hangs after a "looking for databases..." line? > > When it hangs, aborting via CTRL-C was not possible. It works now, > albeit not perfectly: > > $ ./syncevolution --configure --template webdav > syncURL=http://192.168.1.100:9000/ username=foo password=bar > target-config@webdav-temp [INFO] creating configuration > target-config@webdav-temp [INFO] addressbook: looking for > databases... ^C[INFO] Asking to suspend... [INFO] Press CTRL-C > again quickly (within 2s) to stop immediately (can cause problems > in the future!) ^C[INFO] Aborting immediately ... [ERROR] error > code from SyncEvolution aborted on behalf of user (local, status > 20017): aborting as requested by user > > It would be good to make the CTRL-C handling code aware that it > can abort immediately instead of doing the intermediate "asking to > suspend" step, which only makes sense for sync sessions. Is that > confusing enough to warrant delaying 1.3, or can I add that later? >
Quite a bit of this is over my head, and I'll leave it to others to give their opinions. However, I think it's definitely better to have some kind of message rather than nothing at all (which leads one to think that the whole system has locked up). I've noticed some odd behaviour with the memo sync. I have two installations of SyncEvolution, on different machines. One uses calDAV and the other uses EDS. They interface with the same Radicale memo file. Each installation is used with one phone only. I have two memos which were created on the 6120c phone and introduced into the system via calDAV sync. Now they seem to update themselves on the E63 every time I sync the E63 via EDS. No other memos are doing this. I'm happy to provide logs if needed. Jane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP5TiAAAoJEERzSJEx033j7tIH/1m23PkI+F3ACqBnupQL3Psr jb9ZxaCBreYa1AAI3hV7k3eVJUBmZGkKdVksMEkdVPfbpm8L42t6FePcrzyq2a/K a/XIyuihNxMMwknqhtkjmWxTIqCc7m5BEUDSRsYVEfNke+xiWGSEh4Bn3VR/z4Ty 4rz3UFHDzoWgbYMA0A8qNgk9ZmeL6vrlsm7mLtFlXhaOyDUfcbAgk9qRc0ENZkjX 3wQ1L/rss58bQM6aY+1fqatHEeIj0NaWzH5Zk8EK2U7RoPpCcoqmfoqAlfvLHufM kN9n2VR+xQ2kyuvsndLlZZCvmWVp+Pt70wU96Z800tuxzc8uVD1a9OPTCNO+XCc= =uTsy -----END PGP SIGNATURE----- _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
