Hi,
thanks for the patch to fix the "client+statistics" problem with
counting client adds as updates when the server returns 200 for them
instead of 201.
There is one basic problem with your solution: The fact that a entry
in the database already has a change log entry does NOT mean that the
entry has been added to the server which is addressed in this session
(i.e. it does NOT mean that the operation will be a normal replace).
The reason for this is that the changelog is shared between multiple
profiles (multiple servers), and thus the changelog entries are
created when ANY of the profiles first sees the entry. Consider the
following:
1. You add a new record X
2. You sync to server A (with profile A)
3. changelogPreflight detects X as new and creates a changelog entry
for it
4. You sync to server B (with profile B)
5. changelogPreflight will find the changelog entry created in 3 and
not know that X is new for server B
That's why binfileds based clients only send <Replace> - the current
changelog mechanism can't really detect adds. The standard would allow
clients to send <Add>, but does not require it.
I am aware that your solution works with the current SyncEvolution
setup, as it does not use multiple profiles at that time (or
implements them by switching the entire binfile store, including
changelogs). However I can't add it to libsynthesis master as it would
break multi-profile.
Now, to fix the problem in a generic way such that multi-profile will
still work the following could be done:
- extend the changelog to have a modcount_created field, and set it
with the current modcount instead of setting the chgl_newadd flag.
- in implGetItem(), compare the changelog entry's modcount_created
with the current modcount to safely determine if the record is an add
or a replace.
Furthermore, I see no need for sop_soft_add, because if we safely know
which items are really adds, the client can send them as <Add>
commands to the server. Most probably this will also fix the
statistics problem with google and zyb without any other code change
(because I suspect that these simply return 201 for every <Add> and
200 for every <Replace>, without checking if replaces are implicit
adds).
Sending <Adds> openly has another advantage - IMHO statistics should
show what the server actually reports, and not what we think it should
have reported. There might be valid cases where a server can join
incoming adds with existing data and reporting those as "added" would
not be correct either.
Best Regards,
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
