Hi Congwu,
On Aug 13, 2009, at 3:48 , Chen, Congwu wrote:
Ah, I now remember you have mentioned PRO version synthesis client
use multi-profiles sharing the same changelog. On the other hand
syncevolution support multi-profiles with separated changelogs. This
is
why it works for syncevolution but not a generic good solution.
Yes, I realize that it works for Syncevolution.
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.
Thanks pointing the way, I will change it.
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.
I found and also Patrick has pointed out there was some discussions
relates to
this behavior and the conclusion was send Replace for Add is better
than openly
send Add for Add.
http://bugzilla.moblin.org/show_bug.cgi?id=2423#c31
We are a bit conservative to change the client side behavior.
I looked up the discussion, and see that I said that sending <Replace>
for adds and replaces as a client is conformant with the standard
(while the other way around seems not - sending <Add> when in fact it
is replace).
From your experience,
do you think "sending Add for Add" works for most real world servers
as good as the old
"sending Replace for Add" behavior?
Our console clients do that. While they by far don't have the exposure
level as the PDA clients which are binfileds based and thus only send
<Replace>, I haven't experienced or heard about a problem with a
server because of the <Add>s.
I heard that our DEMO console client (the one with text file data,
which is a free download for years now: http://www.synthesis.ch/dl_client.php?bp=CLI&pv=&vtag=&lang=e&lay=desk)
is used by different server developers as a test tool, so I'd say it
is unlikely that this will break interoperability with other servers.
Still, I agree with you that changing client side behaviour should be
carefully evaluated.
My suggestion would be:
- implement the modcount_created stuff so we have reliable information
to distinguish adds and replaces.
- let them travel through the engine as sop_add.
- make the decision if sop_add is sent as a <Replace> or a <Add>
depending
on a config option, so we can use both variants (of course, only
for clients).
- only in case we disguise sop_add as <Replace>, apply the statistics
workaround when checking for status.
This way we would have the choice between a 100% clean behaviour
(undisguised adds) and an optional compatibility workaround mode. If
SyncEvolution testing shows that there are servers having problems
with client-side <Add> you can run it in workaround mode.
Please let me know if that sounds ok to you.
I can help implementing the sop_add and the config option in the
engine, as I'll have to check the implications and apply fixes in the
non-OS part of our codebase anyway.
Best Regards,
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
