[Kde-pim] Making offline/online handling sane

[Georg C. F. Greve]

Hi VOlker,

On Saturday 08 December 2012 15.53:25 Volker Krause wrote:
> That's the other direction, so I'd expect this to be largely unrelated.

Darn.


> > Those items then have a local, but no remote ID, which means they have not
> > actually been pushed to the server, and Akonadi has no recovery from this
> > fairly common [*] scenario, it seems.
> 
> Correct, if the change replay got lost for whatever reason there is
> currently no way to recover from that.

...which, considering that this seems to happen occasionally, is probably a 
case we do want to address before we have people use this in production. 


> Objects without remote ID are perfectly fine (local stuff not yet written to
> the server), the (remote -> local) syncing code ignores those completely to
> avoid losing local changes.

Even when they are two weeks old, while you are online, and have synchronized 
plenty of data in both directions otherwise over the past weeks? Those events 
are and remain local only, and will never be uploaded.


> For items they should not cause any problems, it's a different story for
> collections though, since their content can only be addressed on the server
> if they have a remote ID (at least for those with hierarchical remote IDs,
> such as IMAP and maildir). But IIRC we have recovery code for this in
> CollectionSync since the last Osnabrück meeting?

I'm now on 4.9.3. It definitely does not recover from this.

 
> Is this about collections or items, and what exactly does getting "massively
> confused" mean?

It's about individual events, so items, I presume.

The impression is - but it is not reproduceable enough to really qualify that 
impression further - that once this occurs once, it'll also affect further 
items added to the same calendar that has this issue. So right now I am often 
using the web client to check that data has really made it to the server, 
which is a bit painful.

The other impression is that it slows Akonadi down further, perhaps because it 
tries to somehow recover from this. 

Normally it takes between 2 and 15 seconds to open a mail folder for the first 
time and around 20-40 seconds to open my calendar for the first time (all on 
quad core i5 @ 2.5GHz, 8GB RAM) once in operation things usually get a little 
faster.

When the inconsistency thing strikes, it seems slower than before.

But that may be subjective impression.


> I wouldn't hope for too much there, I think the two issues are largely
> unrelated.

Argh. I was so hoping that when local db <-> server was looked at, this would 
also be improved. But if the remote -> local synchronization gets a speed bump 
that would already help with some other issues, as well.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG				Wondering whether Kolab is for you?
Zürich, Switzerland				Find out at http://kolabsys.com/try

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20121209/aacdc223/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/