[Kolab-devel] Kolab Webservice initiative
bernhard at intevation.de
Wed Nov 9 17:37:55 CET 2011
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
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
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. ;)
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: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/kolab-devel/attachments/20111109/06dcfe76/attachment.bin
More information about the Kolab-devel