Hello!

We have an issue open about detecting unexpected slow syncs and letting
the user decide what to do about that (like using a "refresh from client
or server" instead):
http://bugzilla.moblin.org/show_bug.cgi?id=2416

The current thinking is that if this gets detected during a session, the
affected datastore should be disabled for the session. Then in the next
session, the user must explicitly select slow sync or one of the
"refresh" modes.

The motivation for this is:
      * At least the Funambol server always falls back to "slow" sync
        during an anchor mismatch, even when an incremental one-way sync
        was requested. The Synthesis engine catches that, but the error
        presented to the user in that case is not particular
        informative.
      * A refresh might be a better solution than a slow sync, depending
        on who has the authoritative data.

I'm currently looking into how this could be hooked into clients and
servers, the latter for syncing with phones where our software provides
the UI and controls the sync.

One possibility is to use scripting. In a script for a datatstore I
might be able to use ABORTDATASTORE(). Question: this is documented
under <sentitemstatusscript> - can it also be used elsewhere, like in
<alertscript> or <alertprepscript>?

<alertscript> was my initial candidate for checking the sync mode. On
the server this doesn't work: the script is called directly after
receiving the client's Alert, before checking whether the requested mode
is possible. SLOWSYNC() may return false even though later the session
is done in slow mode. FIRSTTIMESYNC() also isn't useful when using
MD5-based authentication: when a client connects for the first time, the
<alertscript> is not executed because of failed authentication. Then
when it reconnects with valid credentials, the client is known and
FIRSTTIMESYNC() returns false.

For the server I then looked at <alertprepscript>, but I don't see it
getting called at all by the server. Should it be called?

On the client, <alertscript> seems to work as intended. This was a
pleasant surprise because the documentation says "This script is
executed when the server receives an <alert> command from the client."
FIRSTTIMESYNC() works. I don't have access to the sync mode requested by
the client, but that can be added to our script, or rather, the script
can be skipped when the requested sync mode is "slow".

-- 
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

Reply via email to