On Di, 2010-02-02 at 11:23 +0000, Lukas Zeller wrote:
> Hello Patrick,
>
> On Jan 29, 2010, at 19:49 , Patrick Ohly wrote:
>
> > Another peculiarity: on the server, after calling ABORTDATASTORE(),
> > 'ReadSyncSet' is done and items are read from the database as part of
> > 'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
> > Shouldn't the engine skip these steps because the store has already
> > failed?
>
> Yes, it should but a check for isAborted() was missing after calling
> the <datastoreinitscript>. I have added it now (bc0e54ca12 (Added
> check such that if <datastoreinitscript> calls ABORTDATASTORE(), the
> abort gets propagated)), but I'm not sure it will improve the
> situation, as it will cause the entire sync to stop, not just the
> datastore (because a problem in initializing the sync is considered a
> fatal error and will lead to a AbortSession() (at syncagent.cpp:1171).
> On the other hand, I don't think just suppressing operations on that
> single datastore would help a lot - most servers will expect a full
> sync cycle or then get confused.
Aborting the session is what we want - but only after looking at all
datastores that are included in the current message. The goal is to
detect as many datastores as problematic as possible, before aborting
and reporting the problem.
> We could check at syncagent.cpp:1171 if the abort reason status is
> zero (i.e. ABORTDATASTORE(0) called), and if so behave differently,
> i.e. just muting that datastore, but leave the sessing running. But as
> said, I'm not sure that will help with many servers.
I need to experiment with this some more to see whether I can get the
desired behavior.
> > There is SLOWSYNC(), documented as "returns true if session is a slow
> > sync". I found that it also returns true on a client if the session is a
> > refresh-from-client. Is that intentional?
>
> Yes. Within the engine, the term "slow" sync no only covers the two-way slow
> sync, but the "refresh" syncs as well, as these are conceptually slows syncs
> as well. I think the SyncML standard docs used the term like this at some
> point. So:
>
> sync mode "Normal" variant "Slow" variant
> ------------- --------------------------------------
> -------------------------
> two-way normal two-way slow sync with
> data match
> from client update from client ("update server") refresh from client
> ("reload server")
> from server update from server ("update client") refresh from server
> ("reload device")
>
> After all - a full refresh is as slow as a two-way slow sync; all data
> has to travel from one side to the other :-)
Yes, but a "slow" slow sync is slower than a refresh-from-client because
the server doesn't have to do matching (I've seen that take a lot of
time with Funambol) and because no data needs to be sent back.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
