Re: [Evolution] Advice needed for Exchange-like calendaring

[Stuart Guthrie <sfg eurekait com>]

I hope this isn´t getting too much off-topic but it is great to work
through the excellent posts on this issue.

The list of requirements is partially met by a CAP server. I´d say some
of them would be better met by a specialised CAP client talking to the
relevant CAP server.

I´ve added some comments to Kees feature list to put in perspective
where a CAP server fits. 

In essence CAP is simply another protocol for querying and storing
specific data on a server. It describes the client calls and server
requirements. Essentially a bunch of clients can exist. Evolution being
the most obvious one.

Potential Clients:

GUI Groupware
=============
Evolution
Outlook
Mozilla Cal

Web Clients
===========
PHP Groupware
WebCal
etc
etc

Mobile Phone Clients
====================
Nothing yet but a CAP enabled J2ME app beckons.

Tools
=====
Calendar´Agent´ tools
   ie Artificial Intelligence ´Secretaries´ Think clippy on steriods.
ick.
Calendar manipulation tools
   ie You use Evolution to plan events for a group of things due its
nice graphics then run a tool over it to check for clashes and critical
paths using the same CAP protocol to access the data.

The key thing being, they all need to talk CAP. Currently these various
tools talk their own lingo (Evolution at least stores as iCalendar which
is excellent) and so intercommunications is rendered labourious to say
the least.

On Wed, 2003-06-11 at 07:02, Kees Cook wrote:
> On Tue, Jun 10, 2003 at 11:59:08AM -0700, Bryce Harrington wrote:
> > Kees Cook is working on writing up a list of the features that would be
> > nice to have from such a system, which he'll post here.
>
> Here's the document I started.  The requirement list is at the bottom, but 
> I think hits all the important things.  I'm sure there are more high-level 
> requirements that should be added, though...
>
>
> As a side-task of our Calendaring evaluation, we're hoping to write
> something like a whitepaper outlining the design requirements for a
> "real" open source solution to the calendaring void.  A lot of other
> people have started this before, so this should serve as a list of
> references and a brain-dump of requirements for the system to have.
>
> Standards
> ~~~~~~~~~
> Here is a quick run-down of the IETF standards for calendaring.
>
> iCalendar is the text data format of calendaring information.  The analogy 
> to email is an individual email in the "mbox format" (RFC822).
> http://ietf.org/rfc/rfc2445.txt
>
> iTIP (iCalendar Transport-independent Interoperability Protocol) is the 
> method that iCalendar data is sent to other users (event scheduling, etc).
> The analogy to email is the SMTP protocol for sending email to another 
> user.
> http://ietf.org/rfc/rfc2446.txt
>
> iMIP (iCalendar Message-based Interoperability Protocol) is a defined 
> binding of iTIP to Email messages.  This defines an iTIP communication 
> over email systems, reducing the need for an iTIP server.
> http://ietf.org/rfc/rfc2447.txt
>
> CAP (Calendar Access Protocol) is the client-server protocol used by
> clients to access a central calendar storage server.  The best analogy to
> email is the IMAP protocol (RFC2060), which allows a client to manipulate
> server-side folders.  This protocol is still an IETF draft.
> http://www.imc.org/draft-ietf-calsch-cap
>
>
> Sources
> ~~~~~~~
> While searching for open source calendaring solutions, I found several 
> interesting information sources:
>
> ReefKnot has started implementations of the IETF standards (including
> CAP), though activity recently appears quiet (last devel mailing
> list post was Nov 2002).  They have written several good overviews.
> See their "Publications" section for these documents, as well as the
> "Works In Progress" for other whitepapers.
> http://reefknot.sourceforge.net/
>
> OpenCAP is a project that also looks like it's not currently active
> (latest News item was Aug 2002), but has some documentation and some
> design work done for developing a CAP server.
> http://www.opencap.org/html/
>
> A quick discussion I found on extracting Outlook information is here:
> http://laughingmeme.org/archives/000281.html

On the migrate_from_Outlook side, there is also outport at sourceforge
which works quite well at taking outlook calendar --> iCalendar. Stuffs
up recurring events but then that is just a bug.

> Quick Requirements
> ~~~~~~~~~~~~~~~~~~
> Here's a quick set of requirements as I see them right now for making a 
> functional open source client/server Calendaring system.
>
> server-side storage/scheduling
>       - use get(pw|gr)* POSIX calls for local user list or may use 
>           external system (LDAP?)
This is implementation specific in CAP.
>       - manages free/busy and on-server scheduling
CAP does this.
>       - manages delegation/read/write permissions
CAP does this.
>       - manages out-of-band scheduling notifications (email, pages, etc)
Not done by CAP but could be done by a ´helper´.
>       - may manage scheduling events with off-site people (via iMIP or 
>           CAP)
This is not CAP but there is a need for a Web-frontend that talks CAP.
Hopefully PHP Groupware or some such.
>       - on-disk storage must be backup safe (no need to shut down server)
This is implementation specific. If the CAP server backends to a
database (JiCal would), this is definately possible.

> client-side synchronization
>       - keep a local copy of calendar
>       - resync and handling conflict resolution on reconnect

Local copies would be iCalendar.ics files.
Resync would be a ´helper´ task (in a similar way that palm pilot
helpers are to evolution) using a Client CAP to Server CAP model and
perhaps SyncML? Again, this is an additional tool you might put up as a
gap requiring filling.

> client-side scheduling
>       - may manage scheduling calendar events with off-site people 
>           (via iMIP and/or CAP)
The CAP server would not handle this but a CAP Client might. Or a
specific server add-on perhaps?
>       - may keep a list of "cached" users and free/busy from the server 
>         so that offline scheduling can be done
This would be a feature of the Client tool.
>
-- 
Stuart Guthrie <sfg eurekait com>
Eureka IT Pty Ltd