Patrick Ohly wrote:
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).
Defining this may be tricky. Can syncs fail and then work the next time?
I'm guessing we want to keep trying in the general case, and blacklist
some things (like unexpected slow sync).
There should be a error notification at intervals even when the
server/source is disabled from autsyncing temporarily, so user is not in
the dark about this.
>> 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?
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.
The UI would be the wrong place in any case, that is clear.
Conceptually I liked the idea of a small client that runs as a service
and starts "polling" syncs and takes care of notifications. Practically
it may make more sense to keep the dbus server running... Especially
with EDS-change-based syncing in mind. My only real worry is the
constant memory consumption, but I readily admit my ignorance in this
subject: You guys will be much better at deciding this than I am.
Whoever starts these automatic syncs should also take care of notifications.
>> 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
> 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.
desktop notifications is what they want. This is vaguely covered by the
wireframes. I might even go as far as drop all change numbers and just
say "Synced with Google"...
The notification rules for moblin are (from memory):
* there will be a "Dismiss" button automatically
* there can be one additional button, for us that would probably
be something like "Details" and it would open sync-ui.