Hello Chen,
On Jun 13, 2009, at 19:24 , Chen Congwu wrote:
I am still not definite on your message, I will repeat here hoping
you can give
me further clarification.
Regarding the first part of your message, do you mean SyncEvolution
doesn't have
to change tracking MORE THAN ONE STATE per source since it is built
with
BASED_ON_BINFILE_CLIENT? If this is true, the current implementation
in
synthesis client is CORRECT, why do you think this is a conceptual
bug?
Maybe conceptual was not the correct word. The concept is ok, but I
guess I had some confusion between the DB side and the engine side
concept and believe there IS a problem insofar that the engine does
not always call StartDataRead() with the correct tokens. As said, I
have to check the details.
In my own understanding, the change log maintained by binfile glue
layer is the
synthesis client specific information (i.e. which items has been
successfully
sent, which items was not yet sent out or failed during sent out);
while the
change log maintained by SyncEvolution (DBplugin) is db specific
information
(i.e. which items has been changed since last time synthesis client
asked for).
Agreed.
Coming back to the suspend/resume support, assuming last sync is
suspended.
The question is: During next sync, does the synthesis client need
*only* changes
since last time her asked for SyncEvolution(last suspended sync)?
Yes.
Or it needs *both* changes since last suspended sync and changes
since last successful sync?
No - not when built as BASED_ON_BINFILE_CLIENT. StartDataRead() has
two tokens ONLY for the case when the engine is NOT built as
BASED_ON_BINFILE_CLIENT, which is the case for all our servers and
the
ODBC client. In these cases, the DB layer is responsible for all
change tracking. With BASED_ON_BINFILE_CLIENT, the change tracking
requirements for the DB is much simpler.
If the former is true, SyncEvolution only needs to change tracking
*One* state;
Correct.
if the later is true, SyncEvolution still needs to change tracking
*Two* states.
No, altough Patrick and me came to that conclusion in the initial
discussion, it is not needed. The binfileXXX layer makes this
unnecessary.
The spec says: After the suspended session, both the client and the
server can
refuse a resume, in that case a slow sync *must* be issued. This
means during the
next sync (after a suspended session), either a resuming session is
issued or a
slow sync.
Yes, but that's a new requirement in SyncML DS 1.2.1. In 1.2, this
was
not specified, and a server rejecting resume could well request a
normal sync.
I'm not sure why this was changed on 1.2.1. Technically there is IMHO
no reason why a rejected resume must be followed by a slow sync, as
long as the anchors are ok. One guess is that they tried to force
implementors of DS 1.2 servers to actually implement resume and not
fake DS 1.2 compatibility by simply rejecting all resume requests
with
509 and then continuing as if it was a normal sync (which a few did).
Therefore the server only needs changes before last suspended sync
for
resume! (Otherwise, during a slow sync, all the data will be sent to
the server,
no need for any change log).
Two notes:
1) Consider the case where a client is synchronizing with more than
one server (all our PRO clients have multiple profiles). For that,
even without suspend&resume, you need a mechanism to pinpoint changes
on a time scale at multiple points, even more than 2 (if you have
more
than 2 servers). That what the binfileXXX layer was created for in
the
first place.
2) Even in a single server scenario resume, you must be able to
differentiate modifications happened after the original sync and
before the suspend and modifications happened AFTER the suspend. You
are right that this differentiation does not necessarily need a re-
evaluation of the changes since last regular sync as long as the
intermediate layer keeps a list of to-be-resent items somehow.
Best Regards,
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
