[Bug 5632] New: Memotoo and refresh-from-server
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=5632
Summary: Memotoo and refresh-from-server
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: Dries.Decock(a)telenet.be
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
Release Milestone: Undecided
When syncing with memotoo, using a 'refresh-from-server'. All local entries are
deleted, but nothing is added again, losing all information. This for the
calendar, addressbook, ...
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 2229] UI needs a progress spinner
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2229
--- Comment #11 from jku <jku(a)linux.intel.com> 2009-09-17 07:01:50 ---
(In reply to comment #10)
> But the prepares are almost NOPs. There isn't much to do when checking the
> items, so this part is done with very quickly. If the weights are meant to turn
> item counts into real time, then 0.1/0.45/0.45 might be more suitable.
Not item counts, I was trying to estimate the total time in a common sync
situation, which at least for me meant hundreds of prepares and 0-3 sends and
receives.
In the normal case 0.1/0.45/0.45 means smooth progress (with some values of
smooth) until ~15% and then basically jumping to complete. Currently this means
smooth and fast progress until ~50% and then jumping to complete.
The other end of the spectrum is of course the first sync with all the data on
one end (let's say server):
0.1/0.45/0.45 would mean that the progress jumps to ~60% and then slowly fills
up.
Current ratios mean progress jumps to ~75% and then very slowly fills up.
It is possible that the current 'bias' in the weights is a result of using very
large test databases so prepare seemed to take a longer time. I'll be happy to
change if you want to.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 2069] Synthesis error codes and explanation
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2069
--- Comment #4 from pohly <patrick.ohly(a)intel.com> 2009-09-17 06:15:17 ---
(In reply to comment #3)
> Managed to see a 418, which is "Already exists" according to synthesis source.
Can you reproduce it?
> I wonder if this is supposed to come to me or if synthesis should handle it?
> It's not in syerror.h anyway.
Could be that the engine passes through SyncML status codes that it receives
from the server.
--
Configure bugmail: http://bugzilla.moblin.org/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.
13 years
[Bug 2229] UI needs a progress spinner
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2229
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2009-09-17 06:14:01 ---
(In reply to comment #9)
> (In reply to comment #8)
> These the weights used for different operations:
> const float sync_weight_prepare = 0.50;
> const float sync_weight_send = 0.25;
> const float sync_weight_receive = 0.25;
>
> Currently prepare is being weighed more just to counter for the fact that a
> typical sync contains many prepares and few sends or receives.
But the prepares are almost NOPs. There isn't much to do when checking the
items, so this part is done with very quickly. If the weights are meant to turn
item counts into real time, then 0.1/0.45/0.45 might be more suitable.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 2229] UI needs a progress spinner
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2229
--- Comment #9 from jku <jku(a)linux.intel.com> 2009-09-17 05:21:39 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Let's discuss what the throbber should indicate, then make it work like that...
>
> I feel current throbber needs more improvement:
> 1. No percentage hint. For 10-second syncing task, it may need 6 seconds to do
> sync preparation, but the process is only 10% on the throbber. Then it quickly
> begins sync.
> 2. No enough info for what is going on. I tried to sync without username and
> password to scheduleworld. "Starting sync..." with 5% in throbber for about 10
> seconds, then quickly come to "ending sync..." with 95%. It told me nothing. :(
>
> To this topic, I feel spinner/throbber may be helpful to solve #1, but we may
> need to add more steps information to show to user (about #2). Thanks!
For #1 we might be able to add some steps, like stepping a bit when
PEV_SENDSTART, PEV_RECVSTART or PEV_ALERTED comes. My testing back when I
implemented this didn't show any improvement in usability though: most of the
time was spent before those.
The problem in #2 is that we just can't know... We may end up receiving 200
items or 0.
What we can do is tweak the constants used when the progress percentage is
updated, if you think that would help (it doesn't if the problem is that no
progress is shown for a while).
These are current constant progresses:
const float sync_progress_clicked = 0.02;
const float sync_progress_session_start = 0.04;
const float sync_progress_sync_start = 0.06;
const float sync_progress_sync_end = 0.96;
These the weights used for different operations:
const float sync_weight_prepare = 0.50;
const float sync_weight_send = 0.25;
const float sync_weight_receive = 0.25;
Currently prepare is being weighed more just to counter for the fact that a
typical sync contains many prepares and few sends or receives. I'm open to
changes here, these figures were based on very quick testing on my part.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years
[Bug 3603] keyring access rights should be handled by the dbus wrapper library
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3603
jku <jku(a)linux.intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |enhancement
--- Comment #4 from jku <jku(a)linux.intel.com> 2009-09-17 04:38:46 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Note to self:
> >
> > org.freedesktop.DBus.GetConnectionUnixProcessID() returns the pid on Unix. At
> > least on linux '/proc/<pid>/cmdline' gives the process path... this may be
> > overkill though.
>
> Hi Jussi,
> Do you plan to fix this soon? If so, we can change the Priority to P2 now.
> :)
> If we still need to put the fix later, using P3 is enough. P4/P5 means
> nearly NOT-FIXED. Maybe you or Patrick can give some info and help to modify
> Priority (I have no auth). Thank you very much!
I'm making this enhancement, it looks like this issue will be obsolete with the
new api... I'll update then.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years