[Kolab-devel] Kolab Webservice initiative

[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. ;)

> 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. 

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. ;)

Best,
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/20111109/06dcfe76/attachment.sig>