On Thu, 2009-08-20 at 11:12 +0100, Chen, Congwu wrote: > >For "server update/client update" conflicts it becomes more difficult. > >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 update > operation > 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 > > data. > > * 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
