thanks a lot! This was a great explanation (as usual). I will rework the
relevant parts when there is some time available soon (I think I will have
to only replace ITEM_REPLACED with ITEM_OKAY in the contacts backend and
ITEM_NEEDS_MERGE in the calendar/todo backend).
Patrick Ohly wrote:
On Tue, 2016-08-23 at 00:29 +0200, deloptes wrote:
> Patrick Ohly wrote:
> > Is the full code available somewhere?
> No, I still don't know what to do with it and I'm not sure in which form
> I should upload it. Uploading it means maintain it ... etc. I was
> thinking to upload it to the trinity desktop, but still it is not clear
> how it would fit with the different distros. Another option would be to
> add it to syncevolution - perhaps it is even more proper ... anyway short
> answer is no - I could pass a zip file of it .. it's really not much
> code. The last but not least is I do not feel confident because of this
> issue and do not want to "release" is until it is solved.
Fair enough. The common wisdom is to "release early, release often", but
in this case I agree that it is better to ensure that there is no data
loss before making it available to others.
The question is where. We've fixed some UTF related parts of the TDE code,
which was bugging me since the time of opensync and smart phones started
supporting UTF or something more than iso8859.
Slowly it gets mature. I had a wish to implement support for vcal but gave
it up as testing showed there are some issues with handling vcal in the TDE
lib. I still suspect some issues there perhaps UTF related, but no time to
work on this recently.
So while the backend gets mature there are some challenges on the opposite
side, but it is still good to have a plan what to do next.
IMO it would be best to push into syncevolution tree and TDE could apply own
debian rules for building a package which would replace the debian native
package offering tdepim.
Does someone has better ideas?
> So it looks like I misunderstood the ITEM_REPLACED meaning?
> please confirm once again. I have been struggling with these part of the
> code for some time already.
> My questions
> 1. even when update is implemented as del+add and the item has the old ID
> it should return ITEM_OKAY?
> 2. does ITEM_REPLACED means that item has new ID and is to replace the
> old item with the old ID?
ITEM_REPLACED, ITEM_MERGED and ITEM_NEEDS_MERGE all are to be used only
when adding a new item, i.e. uid is empty. In this case, the engine
doesn't know about the existing item in the database and the backend has
to tell the engine about it.
ITEM_NEEDS_MERGE is probably best for handling this situation because
merely replacing the existing item (ITEM_REPLACED) can loose data and
merging in the backend (ITEM_MERGED) is more work to implement.
> Strange is only that I have such issues with calendar+todo only and a
> fact is that it messes totally up in slow sync.
Not sure either. Perhaps it is because calendar items have a UID and
thus additional constraints that don't apply to contacts. ITEM_REPLACED,
ITEM_MERGED and ITEM_NEEDS_MERGE should never be needed for contacts,
because a contact backend typically will never be able to detect when a
new contact that is to be added already exists.
The story about ITEM_NEEDS_MERGE however is still a bit unclear to me. Is it
a suggestion - at least I understand it as such?
I think I lack understanding about it and will look into some of the other
backends to get better insight.
return InsertItemResult(luid, "", ITEM_NEEDS_MERGE);
and there is no delete or add around. It means we find out there is item
with such ID and do nothing - just curious what happens next in theory.
I'll ask here if I need some assistance. Ideas and enlightening is always
welcome of course.