Hi, ...also re-posting here instead of our more private thread, in order to get these things into public, for the record and for discussion: Am Donnerstag 05 April 2012, um 11:09:37 schrieb Milan Crha: > Hi, > just an out-of-thread idea (initially opened in another discussion): > > Thinking of it, dealing with conflicts while writing changes into the > server when in online mode is simple, the backend just returns an error > and doesn't try to resolve anything. Am I right? It should eventually > update the local object, the only question is when and how (if you > notify clients about change, then the editor will notify user about that > change too - he/she can reject editor update, probably because he/she > wants to use his/her changes and write them to the server, thus still > using the old object). Currently, the evo-kolab backend does conflict detection as well as conflict resolution. The latter mainly since there has not been an infrastructure in E-D-S to request user interaction back in 2.30 era. When configuring a Kolab folder in Evo for PIM use, the user can, basically, select from the following options for sync conflict resolution, which are applied whenever an object is being written onto the server, be it in online mode or while synchronizing after an offline session: * Take newest (relies on the multiple client's clocks to be in sync, since the Kolab server does not help us with that - it just stores mails, and the time when an object is stored onto the server is not necessarily the time when it has been modified - the modicifation could have taken place hours before, while in offline mode, so we need to use the object's modtime here) * Take remote (server side object wins) * Take local (locally modified object wins) * Create dupe (the result is having two distinct objects, local one is assigned a new, collision-free object UID) As soon as the evo-kolab infrastructure for requesting user interaction is ready (will be a temporary solution I think), the above list will contain one more entry: * Always ask (which will pop up a dialog for each sync conflict, in which the user can choose one of the aforementioned four options for resovling the conflict at hand) That's it, basically. For anyone who is interested to have a look at the evolution-kolab sources and the implementation there: The actual cache-implementing object KolabMailSideCache does not have to do anything with all of that, it is on the KolabMailSynchonizer object to decide which object wins and whether a locally cached object will just be dropped and replaced by that of the server, or whether the locally cached one will be written onto the server and after succeeding with that being deleted from the cache. The KolabMailSideCache does not even have a facility to ask what has changed, the bookkeeping for that is done in a KolabMailInfoDb instance. These are all part of the main engine object, KolabMailAccess, and located in the libekolab/ directory in the evolution-kolab source tree. Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.