http://bugzilla.meego.com/show_bug.cgi?id=698 Summary: Improve progress functionality in DBus API Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: enhancement Priority: Low Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=7134 Description From yongsheng zhu 2009-10-20 23:12:27 PST (-) [reply] 'Progress' calculation is much more complex. Open this bug entry to track discussions on how to calculate 'progress' smartly and precisely. A reference bug entry is bug#2229. ------- Comment #1 From yongsheng zhu 2009-10-20 23:14:18 PST (-) [reply] ------- Here is a comment from Patrick's mail, posted here: Perhaps we can turn the float constants above into an array of variables, indexed by ProgressState, which get set (and updated) depending on what kind of sync is detected? ------- Comment #2 From pohly 2009-10-22 05:07:56 PST (-) [reply] ------- *** Bug 2413 has been marked as a duplicate of this bug. *** ------- Comment #3 From yongsheng zhu 2009-10-25 23:29:30 PST (-) [reply] ------- I collected PEV events and time data for different kinds of sync modes and many usage scenarios and got below conclusions: 1) The highest time cost is network transport. In all of these scenarios, they take about 70~90% of total time based on my network conditions. It may varies under different environments. But it should be the highest one, not sync modes. 2) Based on the 1st truth, all of them could be partitioned into 3 big steps: session init, data preparation, send and receive, session end. In a widely common usage scenario(such as two-way sync without errors, others sync mode are the same), each step contains one send/receive of syncML message. Another reason to adopt this partition is that each step has a decided started/ended PEV command so we can easy to track. 3) Here are detailed descriptions for 3 steps: Session init step: clients prepares auth info and device info, set up connection and send them to server and server returns auth result and its device info. Data preparation, send and receive: client prepares its backend data(if has) and sends them to server. Server receives them and sends status and its own data items to client(if has and needed). Session end: client parses server's data items and stores them in backend and send a message to end the session. 4) The temporal distribution is not equal for 3 steps statically. And also step 1 and step2 don't know what percent they will take. Reasons could be summarized as: each step may not have only one send/receive messages 5) Major possible reasons to affect progress: sync errors and the number of network transport. 6) Possible time factors in each step: Session init step: transport connection setup, authencation(zyb could make us send 3 times authencation info) Data preparation, send and receive: the number of data items, which could increase the number of message sending and receiving; reading data from backend Session end: data writing to backend 7) Based on the above description, my proposal is that progress calculation should be based on 3 big steps and networks transports since there are the most important. Though in step1 and step2, we can't know what extractly progress we are, but I'd like to change percentages dynamically according to current step information. For example, in the step2, if we find many data items to be sent in many messages, we'd increase percentage of step2 and reduce percentages of step3 dynamically. ------- Comment #4 From yongsheng zhu 2009-10-25 23:40:01 PST (-) [reply] ------- Created an attachment (id=3211) --> (http://bugzilla.meego.com/attachment.cgi?id=3211) [details] time and progress event data The data for time and progress event is uploaded, which is used to track time distribution for different usage scenarios. If interested, you could have a look ------- Comment #5 From yongsheng zhu 2009-10-26 20:42:34 PST (-) [reply] ------- Each syncML message sending/receiving could use much time. This could make some *big* jumps of percentages,. For example, before sending, progress percentage is 5%, however, after many seconds, progress percentage jumps to 40% and there is no update since there is no event between sending and receiving. so we may have to update percentage in the sending/receiving. ------- Comment #6 From yongsheng zhu 2009-10-29 02:12:07 PST (-) [reply] ------- (In reply to comment #5) I'd like to add one timer to update progress info to dbus-client in the processing of sending/receiving and send signals at regular intervals. This prevents client's progress bar changed dramatically. This could be done through time estimation of send/receive for the first time. ------- Comment #7 From pohly 2009-10-29 03:28:25 PST (-) [reply] ------- (In reply to comment #6) I'd prefer to get the sync-UI working with the new progress implementation before tuning it further. Then it will be easier to literally *see* how it behaves in practice. The current implementation can be merged into master as it is without the message send/receive part, once you declare it ready for merging. If you don't know what to work on next, there are several more urgent issues (bug #6376, #6548, #7555). Also, having comprehensive test coverage of the new D-Bus API is critical now. We should be sure that it works before Jussi spends too much time debugging it when he could work on the sync-UI instead. ------- Comment #8 From pohly 2009-11-10 08:20:32 PST (-) [reply] ------- (In reply to comment #7) Merged. We can tweak the implementation later on. ------- Comment #9 From jku 2009-11-16 13:10:05 PST (-) [reply] ------- (In reply to comment #7) This is now possible in jku-dbus-update branch. -- Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.