[Kroupware] Kolab iCal <-> IMAP converter

[Diego Rivera]

On Wed, 2003-05-28 at 11:23, Jason A. Pattie wrote:
> Diego Rivera wrote:
> > To mitigate the impact of ical generation on every request, a simple
> > caching approach might help:
> 
> Our thoughts were that the ical file would be generated somehow each
> time a change occurred on the IMAP server for that user's calendar data
> and pushed to the Web Server.  The Web Server would only do the job of
> serving up the file (i.e., static content) and not do any processing at all.
> 
> But on further analyses, it seems appropriate to do the processing on
> the Web Server, but the issue is that do we just have an ical user that
> has access to everyone's folders?

I think having an "ical_publish" user, who has read-only access to
everyone's Calendar folder would not be so bad.  ACLs could be used to
forbid ical_publish from reading a particular user's folder and thus
block any further re-generation of the ical stuff.  The php page I
mentioned could also detect this (i.e., nothing to publish) and generate
an empty ical file for those requests (or return an error...etc).

The web-UI (even the kroupware client) could have a link/button to the
effect of "Allow publishing of my F/B info", which would trigger the
appropriate ACL changes.


>  or can we gather the user's
> authentication information for the IMAP server in order to be able to
> individually read their IMAP folder(s) on the server?

Gathering user info is a no-no in my mind.  It opens up all sorts of
attack possibilities.

I don't see that many problems with the approach I've described - except
the added overhead of creating the appropriate "macro" buttons to effect
the necessary ACL changes.

> 
> > 
> > Opinions?
> > 
> > Should I go and get my dunce cap again?  :)
> 
> Not at all!  That was an excellent explanation of the issues involved
> with many of the approaches that can be taken to solve this problem.

WHEW!!  :)

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?  I realize it's a major change from what's working and what's
being done, but bear with me.

If the calendaring stuff is in LDAP, it could be trivial to implement
proper concurrency since LDAP already handles this (i.e., can't change
an entry somebody else is changing or deleting).

The stuff could be accessible from anywhere using LDAP/SSL or LDAP/TLS. 
A local (remote?) slurpd instance running on a shell backend (or custom
backend) could handle the re-generation of the ical published file
(i.e., regeneration occurrs truly when a pertinent change happens, as
part of the overall LDAP replication process).

Even "worse" ( :) ), a customized backend could be built to fire off
triggers/processes whenever certain addition/modification/removal events
occurr on certain entries (or branches).

Also, I have a sligthly off-topic question: why was the contact stuff
put in IMAP instead of LDAP?  i.e., if the client was already going to
access the master LDAP contact list, why not allow each user to have
their own contact list in the LDAP server anyway?

It's just a matter of correctly configuring OpenLDAP to allow users to
modify their own assigned branches.  On the client side, since the work
of accessing the global directory is already done, the same work can be
leveraged to access the user's personal contacts.  Writing code to write
new/changed/deleted entries to LDAP shouldn't be too difficult once
that's done.

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.


-- 
===========================================================
* 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/08ec6d05/attachment.bin