29c08781ef
Zimbra has a principal URL that also serves as home set. When using it as start URL, SyncEvolution only looked the URL once, without listing its content, and thus did not find the databases. When following the Zimbra principal URL indirectly, SyncEvolution did check all of the collections there recursively. Unfortunately that also includes many mail folders, causing the scan to abort after checking 1000 collections (an internal safe guard). The solution for both includes tracking what to do with a URL. For the initial URL, only meta data about the URL itself gets checked. Recursive scanning is only done for the home set. If that home set contains many collections, scanning is still slow and may run into the internal safe guard limit. This cannot be avoided because the CalDAV spec explicitly states that the home set may contain normal collections which contain other collections, so a client has to do the recursive scan. When looking at a specific calendar, Google CalDAV does not report what the current principal or the home set is and therefore SyncEvolution stopped after finding just the initial calendar. Now it detects the lack of meta information and adds all parents also as candidates that need to be looked at. The downside of this is that it doesn't know anything about which parents are relevant, so it ends up checking https://www.google.com/calendar/ and https://www.google.com/. In both cases Basic Auth gets rejected with a temporary redirect to the Google login page, which is something that SyncEvolution must ignore immediately during scanning without applying the resend workaround for "temporary rejection of valid credentials" that can happen for valid Google CalDAV URLs. The sorting of sub collections is redundant and can be removed, because sorting already happens when storing the information for each path. When scanning Google CalDAV starting at https://www.google.com/calendar/dav/, the main calendar gets listed by Google first, but because we reorder by sorting by path, it ends up last in the SyncEvolution database list and thus is not picked as default. This needs to be fixed separately by preserving the server's order. |
||
|---|---|---|
| .. | ||
| backends | ||
| dbus | ||
| gdbus | ||
| gdbusxx | ||
| gnome-bluetooth | ||
| gtk-ui | ||
| gtk3-ui | ||
| syncevo | ||
| synthesis-includes | ||
| templates | ||
| async.patch | ||
| client-test-app.cpp | ||
| README.h | ||
| README.templates | ||
| shlibs.local | ||
| src.am | ||
| syncevo-local-sync.cpp | ||
| syncevolution.cpp | ||
| testcases.am | ||
| valgrind.supp | ||
The configuration templates in "templates" get installed into $(datadir)/syncevolution/templates. When adding/changing a new server, then only enter the properties which need to be changed here so that the default values can be used for the remaining properties. An icon can be added here for servers. The file name must start with "icon". Server configurations must be kept in sync in three different places: - here (if a server is installed as files) - in SyncEvolutionConfig.cpp's EvolutionSyncConfig::createServerTemplate() - in SyncEvolutionCmdline.cpp's test server configs - in test/test-dbus.py testGetConfigsTemplates() Note that server icons must come with a suitable license that allows redistribution.