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 <patrick.o...@intel.com> 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?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
