6:27 p.m.
[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]
Hi guys,
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
something.
- Jussi
Summary for things related to the user interface:
Short term:
* 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
window
Mid to long term
* fix the main window to better support automated syncs, emphasizing
more sync "history".
* notifications
* 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
settings.
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:
*** Recovery:
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
history.
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 settings.
The "manual services" list will be removed and the "Add a service
manually" button will just add a new service into the main list
1:51 a.m.
On Thu, 2009-09-17 at 09:27 +0100, Jussi Kukkonen wrote:
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
something.
My main takeaway was the desire to have automatic sync in 1.0, even if
it is only based on regular polling. We should do the automatic sync as
long as there are no errors. Once we encounter an error, we need to stop
the automatic sync, notify the user and let the user deal with it.
Errors in this case are:
* unexpected slow syncs
* nothing else?!
We also identified the need to keep track of a simple string in the
session report for each item that was modified during a sync. We have
this in the sync log and the console output from the SyncSourceLogging
class, but we don't record this in a machine readable format. It is also
not in the D-Bus API (yet). Providing this information for items deleted
locally before the sync is only possible if the string is buffered.
The D-Bus interface needs an API for a generic server->client->server
communication, used for passwords at the beginning, later perhaps also
for other requests.
Open question do the designers: what information about a peer is
necessary to represent it in the GUI?
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
12:53 p.m.
Errors in this case are:
* unexpected slow syncs
* nothing else?!
Mistakes in the backend?
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?
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.
If placing regular polling in syncevo-dbus-server, after completing sync, it will send
sync reports
to gui. It has to start gui if needed. This makes syncevo-dbus-server depend on gui.
Cheers,
Yongsheng
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Tuesday, September 22, 2009 11:52 PM
To: Jussi Kukkonen
Cc: SyncEvolution
Subject: Re: [SyncEvolution] notes from design meetings last week
On Thu, 2009-09-17 at 09:27 +0100, Jussi Kukkonen wrote:
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
something.
My main takeaway was the desire to have automatic sync in 1.0, even if
it is only based on regular polling. We should do the automatic sync as
long as there are no errors. Once we encounter an error, we need to stop
the automatic sync, notify the user and let the user deal with it.
Errors in this case are:
* unexpected slow syncs
* nothing else?!
We also identified the need to keep track of a simple string in the
session report for each item that was modified during a sync. We have
this in the sync log and the console output from the SyncSourceLogging
class, but we don't record this in a machine readable format. It is also
not in the D-Bus API (yet). Providing this information for items deleted
locally before the sync is only possible if the string is buffered.
The D-Bus interface needs an API for a generic server->client->server
communication, used for passwords at the beginning, later perhaps also
for other requests.
Open question do the designers: what information about a peer is
necessary to represent it in the GUI?
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
3:01 p.m.
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.
6:32 p.m.
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
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.
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.
- Jussi
2:31 a.m.
Am Mittwoch, den 23.09.2009, 11:32 +0300 schrieb Jussi Kukkonen:
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.
I also like this very idea. This is basically what my idea with Genesis
was about: Have a small app that is running in the session, handling
automated and manual syncs, and notifying about changes.
The configuration thing I added to Genesis later on was meant to take
the pain out of configuring SyncEvolution. This is now mainly redundant
in Genesis, because sync-ui makes a good job here. If SyncEvolution
would also include a small autosync and notification app, this would
cover the current use case of Genesis.
I think it really makes sense to have all in one place and to develop
sync-ui and SyncEvolution together. If Genesis’ days were counted
because Upstream develops a superior solution, I wouldn’t be sad. I just
would like to know if this is where you’re heading.
> 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.
If sync-ui and that notification client are not exclusively meant for
Moblin, one should think about the different notification
implementations. Ubuntu removed the Actions (i.e., those additional
buttons) from the notification system. This is, as far as I know, in
line with the spec, but one should then poll for the implementation
capabilities, and slightly adjust the notification.
Cheers,
Frederik
12:05 a.m.
On Thu, 2009-09-24 at 17:31 +0100, Frederik Elwert wrote:
I think it really makes sense to have all in one place and to
develop
sync-ui and SyncEvolution together. If Genesis’ days were counted
because Upstream develops a superior solution, I wouldn’t be sad. I just
would like to know if this is where you’re heading.
We'll keep discussing it here on the list as much as possible, so just
keep reading and hopefully also commenting ;-) I hope you'll continue
with that even if you decide one day that the upstream UI is good enough
and that Genesis is no longer needed.
--
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.
5:12 a.m.
Am Donnerstag, den 01.10.2009, 16:05 +0200 schrieb Patrick Ohly:
On Thu, 2009-09-24 at 17:31 +0100, Frederik Elwert wrote:
> I think it really makes sense to have all in one place and to develop
> sync-ui and SyncEvolution together. If Genesis’ days were counted
> because Upstream develops a superior solution, I wouldn’t be sad. I just
> would like to know if this is where you’re heading.
We'll keep discussing it here on the list as much as possible, so just
keep reading and hopefully also commenting ;-) I hope you'll continue
with that even if you decide one day that the upstream UI is good enough
and that Genesis is no longer needed.
Sure. :-)
Cheers,
Frederik
12:17 a.m.
On Tue, 2009-09-22 at 16:51 +0100, Patrick Ohly wrote:
My main takeaway was the desire to have automatic sync in 1.0, even
if
it is only based on regular polling. We should do the automatic sync
as
long as there are no errors. Once we encounter an error, we need to
stop
the automatic sync, notify the user and let the user deal with it.
Errors in this case are:
* unexpected slow syncs
* nothing else?!
Discussion ongoing on the list, reminder in Bugzilla: #6378
We also identified the need to keep track of a simple string in the
session report for each item that was modified during a sync.
#6377
The D-Bus interface needs an API for a generic
server->client->server
communication, used for passwords at the beginning, later perhaps also
for other requests.
Added, needs to be implemented. #6376
Open question do the designers: what information about a peer is
necessary to represent it in the GUI?
#6379.
Wow, four issues in a row. Is there a price for "most issues filed per
minute"?
--
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.
4:31 p.m.
Discussion ongoing on the list, reminder in Bugzilla: #6378
Together with implementation of DBus API, I'd like to take over this and discuss
issues of design and implemenation with you.
Is it ok?
Cheers,
Yongsheng
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Wednesday, September 23, 2009 10:17 PM
To: Jussi Kukkonen
Cc: SyncEvolution
Subject: Re: [SyncEvolution] notes from design meetings last week
On Tue, 2009-09-22 at 16:51 +0100, Patrick Ohly wrote:
My main takeaway was the desire to have automatic sync in 1.0, even
if
it is only based on regular polling. We should do the automatic sync
as
long as there are no errors. Once we encounter an error, we need to
stop
the automatic sync, notify the user and let the user deal with it.
Errors in this case are:
* unexpected slow syncs
* nothing else?!
Discussion ongoing on the list, reminder in Bugzilla: #6378
We also identified the need to keep track of a simple string in the
session report for each item that was modified during a sync.
#6377
The D-Bus interface needs an API for a generic
server->client->server
communication, used for passwords at the beginning, later perhaps also
for other requests.
Added, needs to be implemented. #6376
Open question do the designers: what information about a peer is
necessary to represent it in the GUI?
#6379.
Wow, four issues in a row. Is there a price for "most issues filed per
minute"?
--
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
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
7:22 p.m.
On Thu, 2009-09-24 at 07:31 +0100, Zhu, Yongsheng wrote:
> Discussion ongoing on the list, reminder in Bugzilla: #6378
Together with implementation of DBus API, I'd like to take over this
and discuss issues of design and implemenation with you.
Is it ok?
Okay, but let's finish the current work on the syncevo-dbus-server
first.
--
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.
12:05 p.m.
Next, I'll work on 'getProgress' issue.
Cheers,
Yongsheng
-----Original Message-----
From: Ohly, Patrick
Sent: Thursday, September 24, 2009 5:23 PM
To: Zhu, Yongsheng
Cc: Jussi Kukkonen; SyncEvolution
Subject: RE: [SyncEvolution] notes from design meetings last week
On Thu, 2009-09-24 at 07:31 +0100, Zhu, Yongsheng wrote:
> Discussion ongoing on the list, reminder in Bugzilla: #6378
Together with implementation of DBus API, I'd like to take over this
and discuss issues of design and implemenation with you.
Is it ok?
Okay, but let's finish the current work on the syncevo-dbus-server
first.
--
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.
4735
days inactive
4749
days old
syncevolution@synevolution.org
11 comments
4 participants
participants (4)
-
Frederik Elwert -
Jussi Kukkonen -
Patrick Ohly -
Zhu, Yongsheng