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 <[EMAIL PROTECTED]> Eureka IT Pty Ltd _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
