On 05/19/2011 02:25 PM, Patrick Ohly wrote: >> I'm currently wondering whether the "uri" property should be set >> automatically as part of the first sync, if it wasn't set before. That >> way we avoid the risk that the discovery phase suddenly picks a >> different database, for example because a new database was created on >> the server later. > > Note that this should be "database", not "uri". I think using that is > the right approach. Less special cases, user directly sees what sync > did. > > In terms of implementation: setting this property may go into the > endSync() callback. A complication is that for CalDAV, this method is > called in the wrapper MapSyncSource and not in WebDAVSource. > > Attached a patch which shows how this could be done. I verified that the > URL is stored after a sync, but then using it again with Yahoo fails. It > asks for credentials by redirecting to a log in page - not useful. I > haven't checked this further.
Patrick mentioned this problem was a trivial URL encoding bug. I've looked at the patch, looks good to me. >> Changing the uri later on should force a slow sync. Not implemented at >> the moment, though: https://bugs.meego.com/show_bug.cgi?id=693 > > We might have to be more careful here. Consider this: > 1. User sets up synchronization of system calendar with CalDAV > calendar A. > 2. synchronizes => system calendar contains events from A > 3. User changes to calendar B. > 4. SyncEvolution detects need for slow sync, asks users what to do, > user accepts slow sync => events from calendar A copied to B. > > The "asks users what to do" is part of the slow sync handling in the > command line and the GTK UI. We don't have this concept in Tablet (yet). > See the "preventSlowSync" setting. > > Without detecting the need for a slow sync (current state of the source > code), we get: > 1. User sets up synchronization of system calendar with CalDAV > calendar A. > 2. synchronizes => system calendar contains events from A > 3. User changes to calendar B. > 4. SyncEvolution does a normal sync. Change tracking sees this as > removal of all items from A, with all items from B added. If > (unlikely) item names are not fully disjunct, then these items > will be seen as updated unless (even more unlikely) they happen > to have the same eTag => system calendar will be identical to B. > > Perhaps this is what we want in such a case? > > The "likely" part worries me a bit. I think it'll work in practice, but > there is no 100% guarantee. I agree with this approach. It'll allow the client to Do The Right Thing once slow sync forcing is implemented. Doing a normal sync until then and also when slow-sync-handling is not enabled sounds right: There may be a risk involved but changing the database is (as far as I can see) a hack, not something we absolutely need to be prepared for. - Jussi _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
