http://bugzilla.moblin.org/show_bug.cgi?id=6378
--- Comment #8 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-01-27 23:09:20 PST
---
(In reply to comment #6)
(In reply to comment #5)
> 1. For bluetooth, I learned from discussion on jabber we don't do auto sync via
> it due to the cost of bluetooth.
We can allow the user to do it, but he should be warned that it will be costly
in terms of power. Therefore let's not create special cases for the different
transports if we can avoid it.
so for those paired bluetooth devices, we give users
the rights to do automatic
sync. The default is off.
> 2. For network, first check whether the network is up, which
depends on
> Presence checking. If yes, send a package( to be defined) to server and try to
> contact it. If getting response as expected, do automatic sync.
Start a sync normally, if we get a response, continue. No special package
needed. For this to work well, we have to make starting a sync cheaper:
- don't dump databases unless a source is active
- same with change detection
what does 'same with change detection' mean
here? The backend change detection?
I don't think we can predict whether the peer will remain
present. We probably
have to use "peer has been around for a configurable duration" as an
approximation for that. Checking power would be nice, but is not essential.
how do
we detect 'peer is around'? by detecting network and bluetooth presence?
the main view. The main view has:
* button to sync all shown sources (current "Sync")
* autosync-toggle per source
* sync button per source (possibly hidden if autosync is on)
I'm sure Nick is open for negotiation though...
what about 'interval'?
a global option or peer-specific or source specific?
--
Configure bugmail:
http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.