[Kolab-devel] Fwd: Re: CalDav reaches the standards track]

[Stephan Buys]

Hi Martin, 

My suggestion would be to have the calendar entries stored in a
database, and on Cyrus write an extension which would simulate
the original manner of keeping the calendar items as xml attachments
to mails by generating them on the fly whenever the folder is
queried (aternatively you can generate the database contents from
Cyrus but then you'd have duplication)

The next step would be to expose the database via an http middle
layer (interpreting the caldav xml queries and returning appropriately
formatted results).

I think everybody agrees that currently CalDav (at least the 
open-source implementations like chandler and cosmo aren't 
production ready yet). The only reason I'm suggesting it 
is because it seems to be the only real standard, or at least
hope for a groupware sharing standard. Keeping in mind that
Chandler, Outlook, Sunbird and Apple support caldav.

I think it would be wise to watch this space, that in time 
users could point whichever client they want at their Kolab 
server.. Other issues like atom level permissions, issues
with syncing shared imap folder at the same time, etc. would 
also dissapear.

Kind Regards
Will Verschuur


On Wed, 2007-04-11 at 08:26 +0200, Stephan Buys wrote:
> See this?
> ----------  Forwarded Message  ----------
> 
> Subject: Re: [Kolab-devel] CalDav reaches the standards track
> Date: Tuesday 03 April 2007
> From: Martin Konold <martin.konold at erfrakon.de>
> To: Kolab development coordination <kolab-devel at kolab.org>
> 
> Am Mittwoch 28 März 2007 schrieb Stephan Buys:
> 
> Hi Stephan,
> 
> > http://www.calconnect.org/
> 
> > CalDav reached the standards track on 20 March 2007. I propose that the
> > Kolab project should seriously support CalDav via our Horde web interface.
> > This will allow us to inter-operate with other standards-based clients as
> > they mature/are released.
> 
> Please explain this to me in more detail. 
> 
> I have the impression that CalDAV is an _ACCESS_ protocol about how to 
access 
> calendar data over WEBDAV/HTTP.
> 
> Kolab currently uses IMAP not HTTP.
> 
> Technically a server component offering CalDAV to clients would be a special 
> Kolab client. It can be developed orthogonally to the current Kolab effort. 
> 
> If it is properly implement it will not interfere with the other Kolab 
> components and I am therefore willing to accept such an effort.
> 
> The situation is very similar to the upcoming Horde based Kolab webclient. 
The 
> Horde Kolab Client is technically a server application offering a HTTP/HTML 
> interface to users.
> 
> BTW: I have to admid that I am not fond of Calendaring Extensions to WebDAV 
> (CalDAV). The definition requires 99 pages for the _access_ definition alone 
> while not solving any issues with the existing iCalendar standard. I have 
the 
> impression that CalDAV was written with relational databases in mind while I 
> believe that calendaring is by its very nature _not_ well suited for a 
RDBMS.
> 
> (It is a fundamental design decision of Kolab to use a hierarchical store 
> instead of a relational db. Kolab uses IMAP for access/transport because it 
> is very well suited to provide extremly efficient access to messages in such 
> a hierarchical store.)
> 
> From an conveptional/architectural point of view access/transport is a 
_very_ 
> minor issue or problem to solve. The real problems are true scalability(*), 
> modelling issues and interoperability. Especially the later (Outlook!) is 
the 
> most difficult part for which CalDAV does not help in any way.
> 
> Regards,
> -- martin
>