[I have a bunch of email just sitting in my outbox, sorry I'm a it late
with this -- meant to send it on Monday]
Here are my notes from the design meetings we had in London, Sep
9th-11th. More or less present were Nick (designer), Patrick and me.
These aren't complete minutes, so Patrick will probably want to add
Summary for things related to the user interface:
* Go through some minor bugs that are still open
* add "Recovery" mode
* don't show sync type in the main window,
put it in service settings
* Change the setting screen so there is no "service dialog":
service settings will open in an expander in the settings
Mid to long term
* fix the main window to better support automated syncs, emphasizing
more sync "history".
* time based synchronization
* EDS event based synchronization
* Any settings that involve "the cloud" will be integrated in Moblin.
This includes Sync settings. This may lead to some problems with the
generic GTK+ UI...
* we'll need to support device to device sync in the ui, which means
we want to have multiple servers/peers "active" at the same time.
This will impact the presentation of the syncs, sync history and
In addition to UI things we discussed the D-Bus api. We talked about how
the server should request info from the user and how we can accomodate
the multi-peer needs within the API we have defined. Patrick will
hopefully talk about this in more detail.
Some more specific notes:
There are two situation where we want to give the user the opportunity
to do potentially destructive SyncML things:
1. user notices that data is corrupt (duplicate items etc).
There will be a button in main window for this case.
2. SyncML server has decided it needs to do a slow sync
on next sync and SyncEvolution is not sure what to do.
We should open the Recovery view when the user opens sync-ui.
The recovery options will be
* Slow sync
* Delete all local data and refresh from server
* Delete all data on server and refresh from local
* Restore a backup
Nick has an action item here:
* define a UI for the "restore backup" case with these req's:
- we have data on at most ten last syncs
(number of changed items, total number of items, etc)
- we can restore before or after each sync
(it might still make sense to only offer restore before a sync,
just to keep things simpler)
- preferably simple to implement...
We need write the explanations for the recovery options as well as a
overall description for both "error cases" mentioned above. Nick will
probably need some assistance from the SyncML-speaking people on that...
*** Unattended syncs
I believe we all agreed that some sort of automatic synchronization is a
"must have" feature -- we cannot expect users to open a synchronization
program. In the long term synchronizing based on EDS events (new
contact, changed event, etc) would be great, but for a start periodic
syncs will do.
However, the UI side will need some changes before we can do that: The
main window needs to be more about syncs and possible problems in recent
We touched the issue of what/who actually drives the unattended syncs,
but this wasn't really solved.
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
It also needs to use notifications to inform the user about syncs.
Implementing #2 (approximately) might be very easy by having a small
process running all the time that subscribes to network events and
initiates syncs a minute or two after a new connection is made... The
footprint would be small so I don't think this would be a problem.
*** Editing configurations "in-place"
There really should not be a "Edit service" -dialog, there should just
be a "Service list" where the services have an expander that includes
The "manual services" list will be removed and the "Add a service
manually" button will just add a new service into the main list