[Kolab-devel] About conflicts and the sync concept (Re: Kolab Webservice initiative)

[Bernhard Reiter]

Hello Hendrik,

Am Thursday, 17. November 2011 15:24:11 schrieb Hendrik Helwich:
> Am Mittwoch, 16. November 2011 11:34:06 schrieb Bernhard Reiter:

> > We already have a "transaction concept", it says that you should
> > create first and then delete. If the connection is interrupted
> > after create, there are two or more objects with the same id for all
>
> you also can have duplicates on the server if two clients are updating the
> same item on the server concurrently and didn't notice the conflict because
> of that.

Yes, it is a normal situation, especially with clients that have an offline 
capability. The two client situation you mention is the same that I am 
mentioning in the next sentence that you have cited: :)

> > clients. And all clients need to be able to resolve this situation
> > because they need to do this anyway if two people edit the same object.
>
> I agree that for the synchronization conflicts every Kolab client needs to
> have a strategy how this should be solved (e.g. server wins).

In case of changes in the contents, one side winning would lose data
of the user. So the Kolab Concept mandates that the user most resolve the 
situation interactively. For a client that is not interactive, it must leave 
both items there for an interactive client to resolve. It has two ways to 
doing so: keeping the same id or labeling one object to a copy with a new id.

> But it can also happen that on the Kolab server there are more than one
> item with the same ID (e.g. by two clients updating an item concurrently or
> an error occurs while a client is updating an item).

Again that is the same situation, the Kolab id of the object is the same.
The id can be seen in the subject of the email.

> A Kolab client needs to have also a strategy for this case (e.g. take
> highest UID). This is an example of the addressed concurrency conflicts
> which could be avoided with a transaction concept that supports isolation.

I am not sure which id you are refering to. The IMAP id or the Kolab object 
id? Probably the IMAP id. If the contents itself of the two objects is the 
same, then yes, the client should just delete one of them.  Otherwise a 
higher IMAP id does not necessarily mean better data. It might be that the 
client writing the object first in a concurrency situation has the better 
data. Only the user can decide this.

> > Often only a human an decide this interactively, this is a reason why all
> > Kolab client SHOULD have a way to interact with the user.
>
> Unfortunately this is not possible for all clients. E.g. the Syncphony
> project (uses Kolab WS) has not the possibility to show a dialog on the
> many supported mobile phones.

True, I can imagine clients that cannot do this.
In this case they MUST leave two objects there as explained above.

> This is the same for the evolution-kolab project where also only a
> background service is adapted which has not the possibility to open a
> dialog in th GUI application.

As Evolution is an interactive application, it sure is possible to bring up 
interaction somehow. Of course if the project doing the Kolab Client 
capabilities for Evolution does not have the ressources to implement this 
through out the whole structure of Evolution, it will stay a structural 
problem. Can you tell us more about the goals of the 
evolution-kolab "project" in the narrorer sense? When will it be concluded?
How does the evolution-kolab initiative is going to continue then?

> > > Maybe the point would be more clear if it is extended that this does
> > > not solve typical important synchronization conflicts due to cached
> > > data?
> >
> > That would be helpful of course as it makes the aim clear.
> > I am not sure that the clarified aim can be reached, though.
>
> Why?

Mainly because I do not fully understand it, I guess. In order for it to be 
implementable it also need to be conceptually possible.

Maybe we even should not call the normal situation that two people edit the 
same object a "conflict". It is a conflict, but not in the sense of database 
locking as I would say. It is a contents or human level conflict. This 
contents conflict cannot be solved.

I believe the value in a Kolab Webservice would be to make some thing more 
accessible. Any client library would also help. However the interface has to 
make sure the necesary resolution of human contents races can be 
interactively resolved if interaction is at all possible.

Best Regards,
Bernhard



-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20111202/b16785ba/attachment.sig>