Patrick Ohly skrev: > On Mo, 2010-03-15 at 11:30 +0000, [email protected] wrote: >> Just wondered if there was any plan to extend the sync-gui interface >> to allow for a more granular sync frequency (i.e. more than daily)? > > I assume you mean the Maemo GUI? > > Ove, are you subscribed to this list?
Sure... I thought I had already answered posts there before (that I wasn't already Cc-ed on)... >> I'm using on a nokia n900 and I'm thinking that it would ideallyt be >> good to have something linked to dbus signals to syncronise a specific >> time period after the last calendar update. Sort of delayed realtim e >> syncing. Only mention it because I'm looking at a wrapper to do this. > > We already implemented regular syncs in the core SyncEvolution, much > like Ove has done for the Maemo GUI (apparently - haven't seen it > myself) and Frederik did on the Genesis GUI. Sync frequency is > configurable there. This depends on running the syncevo-dbus-server, > something that Ove probably doesn't do yet in the Maemo package. Right, they're still based on 0.9. I'm not aware of any immediate need for switching over to the 1.0 codebase. To do period syncs, the Maemo frontend just hooks into alarmd, Nokia's crond-on-steroids thing. In fact, running off syncevo-dbus-server would currently be a disadvantage on a device such as the N900. The Maemo frontend communicates with the N900's Internet Connectivity Daemon, which means: 1) If invoked from alarmd, the frontend asks ICD for an automatic (i.e., not user initiated) connection. If the device is not already connected, the device's system policy will then take effect; if the device's policy is to automatically connect to the nearest network (and there's one nearby), the N900 will do so (and then notify the frontend when the connection is up). If there's no available WLAN and the system settings forbid automatic connection to GPRS/3G, then ICD will reject the connection request, and the frontend will abort. (The user may sync manually later by going into the GUI.) 2) ICD also maintains proxy settings for each configured network. Hence, when roaming between different WLANs (and 3G), proxy settings may change. After the ICD has notified the frontend that the connection is up, the frontend then asks ICD for the current proxy settings, and if any, provides them on the syncevolution command line using --sync-property. The sync then starts. 3) After the sync, the connection is released. If nobody else was using the connection, the device may then disconnect from the Internet again at its leisure, saving power. 4) Also, alarmd hooks into the N900's power management system. The alarmd is capable of waking the N900 from deep sleep, it can even turn the device on at a preset time if powered off (although I don't use this feature, of course). I'm not sure whether the N900 could enter deep sleep if syncevo-dbus-server was running in the background, perhaps it could, but in any case, using alarmd I *know* that none of the user's precious battery power (or similarly precious RAM) is wasted in between syncs. (Of course, once alarmd starts the frontend, some extra CPU cycles may be spent running Python and stuff, but that's at least better than any potential invisible battery drain between syncs, IMO.) Perhaps it would be possible to patch in the ICD interface into syncevolution so that its dbus-server thing could handle it without needing the frontend, but it'd probably not be trivial, and I won't have time to do anything like that anytime soon. So for now, on the N900, the Maemo frontend's autosync is functionally superior to syncevolution's own, and probably will be for a while. The only complaint people seem to have about the frontend is that the Maemo GUI doesn't allow anything but daily sync, but that's only a problem with the user interface, not with the codebase. And the server features etc of 1.0 is probably redundant on the N900. So I just haven't seen the need for trying to port 1.0 at this time. If people really want the Maemo GUI to support other sync periods than daily, they should feel free to send me patches. I only need a daily sync myself, so I might not get around to do it. And besides, I'm not sure what a more flexible GUI should look like, at least without making it much messier. For a patch, you only need to add the configuration GUI, I can probably implement the alarmd magic (yes, the alarmd interface is confusing and poorly documented). And this GUI change would, of course, be needed regardless of whether the clock it controlled was named syncevo-dbus-server or alarmd... _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
