1. progress as percentage:
This will always be a wild guess, because we can't know what the
server will give us, but making just one wild guess is probably
better than many?
I agree. This should be progress by source, so that a client which
wants
to provide detailed information can do so. Overall progress then could
be presented as a combination of the progress of the active sources - if
all of them provide that information.
I think the percentage is not accurate and
hard to calculate. This could make users confusing.
Could it be a combination of a round progress bar without percentage information and
status information to show sync is running
and processed?
Cheers,
Yongsheng
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Monday, August 31, 2009 8:14 PM
To: Jussi Kukkonen
Cc: SyncEvolution
Subject: Re: [SyncEvolution] next generation syncevo-dbus-server
On Mon, 2009-08-31 at 12:23 +0100, Jussi Kukkonen wrote:
> I've been trying to figure out the progress handling logic, but without
> much success. The idea was to move some of it into the server to make
> sure different clients would provide consistent info, but it's not so
> easy. Any comments on these?
1. progress as percentage:
This will always be a wild guess, because we can't know what the
server will give us, but making just one wild guess is probably
better than many?
I agree. This should be progress by source, so that a client which wants
to provide detailed information can do so. Overall progress then could
be presented as a combination of the progress of the active sources - if
all of them provide that information.
2. progress messages:
"Receiving %s", "Sync finished", ...
Clients can get this information from the synthesis signal fairly
easily.
Unless we can wrap a nicer (and fully documented) API around this, then
we probably should stick to the Synthesis signals (but see below about
global state).
3. error messages:
"Server authorization failed", "No space left", ...
Clients can get this information from synthesis signal, but it's not
easy.
Error messages are difficult because we don't have a concept of
localization in the D-Bus API.
The latter two seem like something the clients can deduce from the
synthesis signal (with proper documentation they could even do it
consistently). I think they should be only implemented if we really aim
to remove the synthesis signal at some point.
The first one seems somewhat useful. Should I just add
that as a variable to ProgressSignal?
There's something more fundamentally missing. Suppose a client attaches
to a running session. How does it get the information about the current
state of the session (sync running, active sources, requested and real
sync modes, ...)?
The existing progress signals give a client information about
incremental changes, but not the complete picture. We need a single call
which reports all of relevant bits of information, with "relevant" a
somewhat subjective decision which is likely to change.
If we continue from such a single state with the current progress
signals, then clients have to agree on the state change that is
indicated by the progress signal. Suppose a client doesn't support a
specific progress event and ignores it. If the progress event indicates
a fatal error, then the state shown by the client will differ from that
shown by a client which knows about this error.
Should we perhaps move to a progress signal which sends the complete
state on each state change? This seems a bit wasteful in terms of D-Bus
bandwidth at first glance, but it might be viable. It might even reduce
the D-Bus traffic by bundling multiple Synthesis progress events into a
single state change (if implemented intelligently).
I suggest that we think a bit more about what this state really is, then
design the "get current state" call and finally decide whether it is
small enough to send as progress.
Jussi, what kind of state information is currently kept in the sync-UI?
---
org.syncevolution.Server
GetConfigs
out ARRAY of STRING server
Do we need GetTemplates?
GetConfig
in STRING server
out DICT (STRING source, DICT (STRING key, STRING value))
[NOTE: outer dictionary contains a dictionary for every source and
one dictionary for server config]
The server dict is referenced by an empty source name. The content of a
dict is the same as in the config files and the SyncEvolution command
line --sync-property and --source-property options.
Same here: GetTemplate?
GetReports
in STRING server
in UINT32 start
in UINT32 count
out ARRAY of DICT (STRING key, STRING value)
[NOTE: returns a maximum of 'count' reports (dictionaries),
starting from index 'start' (going from latest to oldest)]
The keys here use a special encoding which we have to document
somewhere.
StartSession
in STRING server
out OBJECT_PATH session
GetSessions
out ARRAY of STRUCT (OBJECT_PATH path, BOOLEAN ready)
signal SessionReady
out OBJECT_PATH path
signal SessionEnd
out OBJECT_PATH path
"Ready" does not mean "running a sync here". It only means
"further
operations can be called on it".
[NOTE: StartSession returns immediately, but the session object
only
exists when SessionReady is signalled.]
org.syncevolution.Session
Close
Okay so far.
Sync
in ARRAY of STRING sources
Instead of selecting sources in the Sync method, should we introduce the
concept of temporarily overriding sync properties? These changes can be
attached to the Session object. That way the sync mode can be changed
for just the next run without permanently changing the configs. Proposal
below.
Abort
Suspend
signal SyncEnd
out UINT32 reason
Because "ready" does not mean "sync running" we probably want a
SyncStart signal, for symmetry reasons, or go for a completely unified
"StateChanged" signal.
GetConfig
out DICT (STRING source, DICT (STRING key, STRING value))
How do we create a new config from a template? StartSession("foobar"),
GetTemplate("scheduleworld"), copy+edit dicts, SetConfig()?
SetConfig
in DICT (STRING source, DICT (STRING key, STRING value))
UpdateConfig
in DICT (STRING source, DICT (STRING key, STRING value))
[NOTE: outer dictionary contains a dictionary for every source and
one dictionary for server config]
Both SetConfig and UpdateConfig could get a parameter "temporarily". If
true, then the change is applied to the Session and not saved
permanently. There has to be an on-disk config for this to work, though.
--
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