On Thu, 2009-08-20 at 11:12 +0100, Chen, Congwu wrote:
>For "server update/client update" conflicts it becomes
>If we send a temporary error code to the server and then an update in
>the next sync ourselves, will the server understand? Should we do the
>merging ourselves, even on clients?
Why do you think the server cannot understand? Are there some examples?
I'm suspicious, that's all. I haven't tried such a situation myself.
Seems servers should likely handle such scenario, i.e. client side
failed unexpectedly (out of disk?)
Servers often decide to not resend an item after a failure, for example
when it triggers a parser error in the client. Clients and server should
be careful to distinguish between transient and permanent errors, but
somehow I doubt that enough attention was spent on this.
However, in this case we don't have to worry about this because the
server doesn't have to do anything, we'll send the item ourselves.
Anyway, we will first have a test first.
>I'd like to see tests for atomic updates be added first:
> * In Client::Source, open two sources and simulate the two kinds
> of conflicts. The source which runs into a conflict should
> return a suitable error (TBD) instead of overwriting more recent
> * In Client::Sync, devise an injection mechanism (possibly hooked
> into the source progress events) which injects conflicting
> changes when the sync is already running.
Agree, I will add it first.
Oh, to make it even more fun I should mention that SyncEvolution must
continue to work without the new API calls ;-) We might be able to get
them into Moblin quickly, but there will be users of older Evolution
releases for several more years.
Please make it so that with --enable-evolution-compatibility, dlopen()
is used to check for the new functions with an if(!= NULL) check in the
code itself which determines whether the functions can be called. This
is important for the binaries published via syncevolution.org
, because a
single binary is meant to work with multiple Evolution releases.
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.