[Kolab-devel] Kolab Webservice initiative

[Hendrik Helwich]

Hi Bernhard,

Am Mittwoch, 9. November 2011 17:37:55 schrieb Bernhard Reiter:
> Hi Hendrick,
>
> Am Tuesday, 8. November 2011 11:04:37 schrieb Hendrik Helwich:
> > Am Dienstag, 8. November 2011 09:26:36 schrieb Bernhard Reiter:
> > >   https://evolvis.org/projects/kolab-ws/
> > >
> > > We also should put it in the wiki.kolab.org if you have not done so.
> >
> > This would be nice. Please tell me if we should do any actions about that
> > point.
>
> just register with the wiki and add it yourself.
> This is the best way to ensure the information is good. ;)

Ok i added a short entry for Kolab WS on the english and german page

> > The use of a Webservice has the benefit that the interface is usable
> > independent from OSs and programming languages and can also be used via
> > HTTP.
>
> True, I fear though that most clients will need a tigher integration
> with the backend functions. Though there will be clients that will
> definately benefit from the webservice approach I think.
>
> > >   * No concurrency conflicts
> > >   Conflicts if Kolab clients are accessing the Kolab server
> > > concurrently can be avoided with the Kolab Webservice.
> > >
> > > I wonder how you are aiming to solve this one. When establishing the
> > > Kolab concept it got clear that conflicts cannot be avoided from a
> > > conceptual point of view. You would have to either give up scaling or
> > > change the human nature. ;)
> >
> > The conflicts which are addressed here are that the IMAP server does not
> > support transactions like a DBMS does. So if a layer like the Kolab WS is
> > put on top of the Kolab server, it can add this feature to server
> > operations which should be atomic but need more then one step. This can
> > be used e.g. if you want to update a contact, which are two operations on
> > the IMAP server (delete old mail, create new mail).
> > This feature can only be enabled for clients who use the extra layer. For
> > normal Kolab clients this would still be seen as multiple steps.
>
> You may be promissing to much then with the goal then. Your approach will
> not eliminate the conflicts that cannot be avoided, e.g. when two people
> edit the same contact or appointment concurrently at the same time.

You are right there are important synchronization conflicts that cannot be 
avoided e.g. clients with an editable cache that is synchronized from time to 
time.
What should be addressed here are concurrency conflicts when different clients 
are reading/writing the same data at the same time. This type of conflicts 
can be avoided by implementing a transaction concept.
A simple example is when client A updates a contact X and client B reads 
contact X at the same time. The update is done in two steps (delete & create) 
and it can happen that this contact gets deleted from client B even if it is 
logically never deleted from the server at all. If it is done the other way 
round you could get duplicates on client B depending on how the Kolab clients 
are implemented.
Maybe the point would be more clear if it is extended that this does not solve 
typical important synchronization conflicts due to cached data?

> The IMAP transaction design by Martin was suited to the situation that the
> clients will have to deal with two or more objects for the same entry due
> to the unavoidable concurrent writing access. So it is perfectly fine, self
> healing and does not need to more "more atomic" as far as I can say. ;)

Maybe i have skipped this part in the Kolab documentation? Do you know where 
this information can be found on the Kolab page?

Best regards,
Hendrik

> Best,
> Bernhard