[Kroupware] Kolab iCal <-> IMAP converter

[Diego Rivera]

On Thu, 2003-05-29 at 18:13, Martin Konold wrote:
> Am Mittwoch, 28. Mai 2003 23:27 schrieb Diego Rivera:
> 
> Hi,
> 
> > Here's something that just occurred to me (I hope it doesn't cost me my
> > newly-found dunce-cap freedom! ) : why not put the calendaring stuff in
> > LDAP? 
> 
> LDAP is by definition incoherent.

Ok...i'm not much of an LDAP expert, but I've seen it done this way on
other areas so I figured I'd ask.

I'm thinking "anything short of a dedicated calendaring server with a
dedicated calendaring protocol" - which wouldn't necessarily be bad -
except none exist that are free software - it would just be a lot more
work and a lot more waiting.

> 
> > I'm assuming there was a lot of discussion in the design/architecture
> > phases before choosing IMAP.  I'm just curious to know what the
> > arguments for/against using Contacts and Calendar in LDAP were, so I may
> > factor them into any future thinking.
> 
> Did you already have a look at the architecture paper on kroupware.kde.org?

yes, but I didn't notice any obvious reason to do so - except the
offline mode that you mention which I should have realized was a big
part of the case all along....dunce cap back on I guess ;).

Also I wasn't aware of LDAP's inherent incoherence that you mention
above - I'm not an expert in LDAP, so excuse the ignorance.

It's hard to think with the dunce cap on...it's heavy, stiffling and
doesn't go well with my shoes :)

----------------

About the ical2imap thing...the arch docs state that "the server mainly
acts as a network storage device in this regard" when referring to
Calendar info storage.

The challenge here becomes : IMAP was never really meant to handle
concurrency as a file store - it's a message store where e-mails are
assumed to be either added or removed, but not ever modified "in
place".  Hence, the modification procedure has to be "add a new one with
the desired modifications, remove the old one" (in whatever order as
required).

Unless non-standard API calls specific to a particular IMAP product are
used, that's what RFC-3501 "says" you can do AFAIK (just checked, and
that's the impression I came out with).

I feel this (using non-standard API) is not the intent, although since
the IMAP server is OSS, doing so isn't that bad a thing.

One way to do it is by some sort of mutex locking generating a message
to indicate a "locked mailbox" status.  Don't like this, cuz processes
can die uncleanly while holding the lock - but it's an (albeit ugly)
option.  The RFC "defines" no natural mechanism for this.

Another way is to have some sort of a summary message serve as an index
to the contents of the calendar directory.  The same concurrency issues
apply when updating the summary message if a change is made.  It would
certainly allow for speedups (using it as a quick-index and data cache)
and load drops, but it brings more problems than it solves, including
the modification concurrency that I so dislike.

I'd love to hear everyone's ideas, since I'm stumped on how to do this
with the stuff that's in place without breaking out of the box too far
out.

Damn dunce cap is starting to get heavy.... :)


-- 
===========================================================
* Diego Rivera                                            *
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>='@', <DOT>='.'                            *
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *
===========================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030529/f1872a69/attachment.bin