> 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 this signal, does 'prepare' mean what the client prepares data items before sync? Could these 3 kinds of actions occur at the same time?
Cheers, Yongsheng -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jussi Kukkonen Sent: Tuesday, September 01, 2009 7:39 PM To: SyncEvolution Subject: Re: [SyncEvolution] next generation syncevo-dbus-server 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 _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
