[Kde-pim] Making offline/online handling sane

[Volker Krause]

On Sunday 09 December 2012 15:08:19 Georg C. F. Greve wrote:
> 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.

Obviously not. I was commenting on your statement that "objects without remote 
ID are not something Akonadi believes in".

> > 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.

For items or for collections? Items have no recovery code, collections do have 
it for some scenarios.

> > Is this about collections or items, and what exactly does getting
> > "massively confused" mean?
> 
> It's about individual events, so items, I presume.

Interesting, did you ever observe it with anything else than events? On Kolab 
these are the types with the highest add/delete frequency, so it is probably 
the most likely one to be hit, but over time it should happen as well for 
regular email then (e.g. when using "keep replies in this folder").

Also, which item does not have the remote id? The IMAP mail or the original 
event? (This is Kolab specific, you have two items there).

> 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.

There's no recovery code for this, so that's unlikely the cause. I can't think 
of a theory for lack of RIDs impacting performance (unless we end up with a 
significant amount of them so that db indexes degrade), so this would need 
some measurements.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20121216/4685e5cc/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/