From edd9bf24df15bd611e0f9767a849f8a03cfb2618 Mon Sep 17 00:00:00 2001 From: Sebastien Robin <seb@nexedi.com> Date: Mon, 12 Jan 2004 08:39:26 +0000 Subject: [PATCH] first submission git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@182 20353a03-c40f-0410-a6d1-a30d3c3de9de --- product/ERP5SyncML/conflict.txt | 95 +++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100755 product/ERP5SyncML/conflict.txt diff --git a/product/ERP5SyncML/conflict.txt b/product/ERP5SyncML/conflict.txt new file mode 100755 index 0000000000..3514780957 --- /dev/null +++ b/product/ERP5SyncML/conflict.txt @@ -0,0 +1,95 @@ +Conflict management with n clients, n >= 2 + + Description : + + - We have 4 boxes, a server A et three clients : B, C and D + - first, A, B,C et D are synchronized + - B change the title of /w/x/truc + - C change the title of /w/x/truc + - D change the title of /w/x/truc + - We do the synchronization in this order : B, D and D + - The server A takes the value of B (because nothing was changed on A) + - there is a conflict between A and C + - there is a conflict between A and D + - So we get on the server A 2 Conflict objets and 1 local object, so that + we can retrieve 3 different versions of the object + - Clients C and D must know that there is a conflict from /w/x + The SyncML protocol doesn't allow us to tell to the client that the + conflict is on /w/x/truc + - We have to be able to get on the server the 3 different objects + - getSynchronizationState should return CONFLICT for each subscription + in conflict. + - for each Conflict object, we should have a getRemoteObject method wich + returns the /w/x/truc object from C and the next Conflict should returns + the object from D + + Result of getSynchronizationState : + + - In the case of a client with only one subscription, this is quite easy, + we should returns the state of the subscription + - In the case of the server, it is more complicated, we can have by the + same time depending on subscribers the following states : CONFLICT, + NOT_SYNCHRONIZED, SYNCHRONIZED... + - So we have to give the state associated with the subscriber, so we should + not returns only a state, but a mapping between subscribers and states + - So we can deduce that we should have a result like this : + [ [subscriber1,state1], [subscriber2,state2]...] + + Howto store conflicts : + + - We should take again the example with the server and the 3 clients + - A, B, C et D are synchronized + - B, C et D change the title and description of /w/x/truc + and also the title and description of /w/x/machin + - We do the synchronization in this order : B, D and D + - The server A takes the value of B (because nothing was changed on A) + - there is a conflict between A and C + - there is a conflict between A and D + - So we have on the server 2 local objects and 8 Conflict objects (DEPRECATED): + - Conflict for /w/x/truc : title for subscription C (DEPRECATED) + - Conflict for /w/x/truc : title for subscription D (DEPRECATED) + - Conflict for /w/x/truc : description for subscription C (DEPRECATED) + - Conflict for /w/x/truc : description for subscription D (DEPRECATED) + - Conflict for /w/x/machin : title for subscription C (DEPRECATED) + - Conflict for /w/x/machin : title for subscription D (DEPRECATED) + - Conflict for /w/x/machin : description for subscription C (DEPRECATED) + - Conflict for /w/x/machin : description for subscription D (DEPRECATED) + - This is bad, we can do a getRemoteObject because in this case we get + only a part of the remote object, we should have only 4 Conflicts + - XXX I have to change immediatly the way of storing conflict in order to + have the following list : + - Conflict1 for /w/x/truc : title and description for subscription C + - Conflict2 for /w/x/truc : title and description for subscription D + - Conflict3 for /w/x/machin : title and description for subscription C + - Conflict4 for /w/x/machin : title and description for subscription D + - The good way is to store a list of xupdate on each Conflict + + Howto solve conflicts : + + - Let's says that we take the object given by Conflict 2 for /w/x/truc and + we take the version given by the server for the object /w/x/machin + - Do we have to solve conflict one by one or when we choose one version for + one Conflict, it will remove other versions ??? + I guess the best way is to just solve conflict one by one, then we are still + free to make another method wich solve for all versions by the same time. + - So we have to do : + Conflict2.manageRemoteObject() + Conflict1.manageLocalObject() # wich is the version of D because of the previous call + Conflict3.manageLocalObject() + Conflict4.manageLocalObject() + - May be we can do a global method, like : + Conflict2.manageGlobalRemoteObject() wich implicitly call + Conflict1.manageLocalObject() + and Conflict3.manageGlobalLocalObject() wich implicitly call + Conflict4.manageLocalObject() + - Conflict2.manageRemoteObject() have to apply all xupdate strings stored + in Conflict2 + - Conflict3.manageLocalObject() have to set the status as SYNCHRONIZED and then + it has to delete itself (Conflict3) -> How ?? + Probably the best way is to call the synchronizationTool wich know everything + about subscription and subscriber. + - At this state, we do have the /w/x/truc of D, and the /w/x/machin of B, and + there is no conflict left, at least on the server side. + - at the time of the next synchronization, the server should send is new version + of /w/x/truc and /w/x/machin to B, C and D, so that everyone is synchronized + without conflict. \ No newline at end of file -- 2.30.9