[Kroupware] Kolab iCal <-> IMAP converter

[Diego Rivera]

On Wed, 2003-05-28 at 14:00, Jason A. Pattie wrote:
> Stephan Buys wrote:
> > Have you looked at the CAP server? (Calendar Access Protocol)
> URL?
> > calsch working group of the IETF? From looking at your mails I would guess
> > that you want to use iCal specifically because so many clients already do.
> Yes.  We are specifically thinking about those clients that do not have
> Kroupware capabilities but already do iCal calendaring (like Evolution,
> Mozilla Calendar, Apple's iCal, etc.).

CAP servers would have been a good idea from the start - except for the
extra work of writing both a CAP client, and adapters for all the
different "legacy" clients such as outlook, evolution, horde, etc.

The IMAP approach helped simplify that greatly, since the client is
reduced to interpreting data that - due to other work already done in
the client as well - is "already easily retrieved" (or, more accurately,
easily retrievable).

Using a CAP server is a good approach though - the best, in my mind -
since it would allow the complete encapsulation of calendaring info into
one server, and possibly aid in scaling upwards if/when it becomes a
bottleneck or machine hog.

> 
> > I suggest you look at what the guys are doing with the Horde framework.
> We are seriously looking at adding Kroupware capabilities to the
> kronolith framework.
> > Diego and Adriaan should be able to help you. They already have reading
> > Contacts (iTip) from IMAP working...
> Cool!

I'm currently working on kronolith...more on that below.

> 
> > Maybe you can somehow tweak the framework to do what you want (like
> > a special view)
> Well, we like the CVS version of kronolith that has the multiple
> calendars view, especially since you can view all your calendars in one
> interface at the same time.  But it currently (as of a few months ago)
> lacks the capability to write events to a remotely stored calendar.  It
> can read them just fine, though.  One of the things we would like to see
> the clients we are using be able to take advantage of is using https://
> URLs instead of just http:// unencrypted calls.  KDE korganizer in KDE
> 3.1.x is capable of doing this, but I don't remember if horde's
> kronolith was able to the last time I checked.

Kronolith allows creation/deletion/reading of cal events via a driver,
which is fairly well abstracted.  Thus, we can do what we please.  The
idea is to re-use the same IMAP stream the IMP mail client would use to
access e-mail, and through that stream get/put/modify all the calendar
events.

This is in progress, although I must admit I'm a bit behind from where I
thought I'd be by now.

> 
> > Also, using the Kolab convention with http_auth you should be able to 
> > specify usernames and passwords with : http://user:pass@myserver (all
> > controlled by the LDAP backend)
> Yes, but that doesn't allow the CGI script on the backend to access the
> IMAP server with that user's authentication information, does it? or
> does passing the username and password on the URL in that way send those
> pieces of information into the CGI environment?  (how secure is that?)
> I would think that you would want, at a minimum, to use HTTPS for that
> kind of transaction.

HTTPS should DEFINITELY be a requirement for this, but then again there
are still race-condition issues when a client publishes their info via
this method, and simultaneously alters the event info using
Kroupware/IMAP.

Granted - it's unlikely Joe Blow will be using both ui's at the same
time, but what about "administered" users: i.e., shared resources that
multiple people can administer?  This would make this condition stand
out, and could cause real-world problems.

> 
> -- 
> Jason A. Pattie
pattieja at xperienceinc.com
-- 
===========================================================
* 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/20030528/a9c6b0a3/attachment.bin