> 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: [email protected] [mailto:[email protected]] 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 [email protected] http://lists.syncevolution.org/listinfo/syncevolution _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
