> Errors in this case are: > * unexpected slow syncs > * nothing else?! Mistakes in the backend? > My main takeaway was the desire to have automatic sync in 1.0, even if > it is only based on regular polling. where to do regular polling, gui or syncevo-dbus-server or a new app? > My thoughts on this: the unattended-sync-client needs IMO to be able to > sync on these cases: > 1. X minutes has passed since the last sync > 2. user logs in or resumes from suspend and more than X minutes have > passed since last sync (this is a specia lcase of #1). > 3. do a sync some time after local data has changed If placing regular polling in gui, then we need start gui all time when logining. But for considering detecting local data changes, syncevo-dbus-server also have to be running all time and sends signals to gui when finding changes.
If placing regular polling in syncevo-dbus-server, after completing sync, it will send sync reports to gui. It has to start gui if needed. This makes syncevo-dbus-server depend on gui. Cheers, Yongsheng -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Patrick Ohly Sent: Tuesday, September 22, 2009 11:52 PM To: Jussi Kukkonen Cc: SyncEvolution Subject: Re: [SyncEvolution] notes from design meetings last week On Thu, 2009-09-17 at 09:27 +0100, Jussi Kukkonen wrote: > Here are my notes from the design meetings we had in London, Sep > 9th-11th. More or less present were Nick (designer), Patrick and me. > These aren't complete minutes, so Patrick will probably want to add > something. My main takeaway was the desire to have automatic sync in 1.0, even if it is only based on regular polling. We should do the automatic sync as long as there are no errors. Once we encounter an error, we need to stop the automatic sync, notify the user and let the user deal with it. Errors in this case are: * unexpected slow syncs * nothing else?! We also identified the need to keep track of a simple string in the session report for each item that was modified during a sync. We have this in the sync log and the console output from the SyncSourceLogging class, but we don't record this in a machine readable format. It is also not in the D-Bus API (yet). Providing this information for items deleted locally before the sync is only possible if the string is buffered. The D-Bus interface needs an API for a generic server->client->server communication, used for passwords at the beginning, later perhaps also for other requests. Open question do the designers: what information about a peer is necessary to represent it in the GUI? -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Hermuelheimer Strasse 8a Phone: +49-2232-2090-30 50321 Bruehl Fax: +49-2232-2090-29 Germany _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
