On Wed, 2009-09-23 at 03:53 +0100, Zhu, Yongsheng wrote:
> Errors in this case are:
> * unexpected slow syncs
> * nothing else?!
Mistakes in the backend?
Yes, that's one possibility. It'll manifest itself in a failed sync. So
how about suspending a source from syncing automatically if it failed?
We should also suspend the server itself if it failed, except when we
recognize the error as transient (network problem, for example).
> My main takeaway was the desire to have automatic sync in 1.0,
> it is only based on regular polling.
where to do regular polling, gui or syncevo-dbus-server or
a new app?
I'd put it into the D-Bus server. Much simpler system design, no need to
add further external APIs. We can load the Synthesis engine on demand to
reduce memory consumption while no sync is running.
> My thoughts on this: the unattended-sync-client needs IMO to be
> 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
detecting local data changes, syncevo-dbus-server also have to be running all time and
sends signals to
gui when finding changes.
The sync-ui shouldn't be started for automatic syncs. The main
motivation for it being automatic is that it runs in the background,
without disturbing the user unless there is a problem.
We probably want some kind of very simple notification mechanism (number
of changed items, sync failed). We can use the normal Linux desktop
notification mechanism for this and/or ask the Moblin designers how they
want to have this handled.
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.