Patrick Ohly wrote:
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.
Ahem, I actually copy-pasted this bit away from the text in error:
In addition to a "total progress" guesstimate, we should provide the
actual counts (as in "received 3/7 contacts") per source, since we'll
be calculating those for the percentage anyway...
This is the "additional" progress signal I was talking about earlier. I
just hadn't finalized it yet...
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, ...)?
[clip]
Yes, sorry for the missing note, I fully agree with what you wrote and I
think we agree on the general signaling idea as well:
The "additional" progress signal I mentioned earlier should take care of
the progress part, we can also add a GetProgress() method if it seems
necessary. I hadn't yet designed this but it should look something like
this:
signal StillUnnamedProgressSignal
out UINT32 progress
ARRAY of STRUCT (STRING source, UINT32 mode,
UINT32 prepare_current, UINT32 prepare_total,
UINT32 receive_current, UINT32 receive_total,
UINT32 send_current, UINT32 send_total)
In a way it's a waste to send all of that when on thing changes, but I
think it makes sense. The above does not include requested sync mode. Is
that needed? Anything else missing?
What a simple application might still want is an easier error indication
(Frederik already commented on this). What I was considering was
modifying SyncEnd like this:
signal SyncEnd
out UINT32 return
ARRAY of STRUCT (STRING source, UINT32 return_value)
Does this make sense if we just forward the PEV_SYNCEND return values in
the source return values? I think it does because most clients could
then skip the synthesis progress signal alltogether and use the two
signals above...
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
