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, 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.

> > 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.

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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to