[standards-jig] FW: [[Osdl_associates] OSDL's June, 2003 Newsletter]

Peter Saint-Andre stpeter at jabber.org
Thu Jun 19 22:36:16 UTC 2003


I thought this was interesting re: our recent discussions of
calendaring...

P

----- Forwarded message from OSDL News <osdl_news at osdl.org> -----

<snip>
  removed unimportant news like OSDL's hiring of Linus Torvalds :)
</snip>

---

4. Group Calendaring

   Kees Cook (kees at osdl.org)
   OSDL Operations

OSDL has grown the the point where it needs a group calendaring 
system.  As Words of Witham details, this is not a simple 
problem.  We started by getting a set of functional requirements 
from our most active calendar users, and then set out to find 
software that met our needs.
  
After spending some time on freshmeat.net to find open source 
solutions, we eventually fell back to hunting for commercial 
solutions, since none of the Open Source tools had everything 
we needed.  

We evaluated:

    * Exchange4Linux
    * SuSE OpenExchange
    * Samsung Contact (was HP OpenMail)
    * Bynari InsightServer
    * eCal Calendar Server
    * SunONE Calendar Server
    * MeetingMaker
    * Crosswind Synchronize
    * Oracle CorporateTime
    * Lotus Notes
    * Novell Groupwise
    * Microsoft Exchange

To see more about our evaluation, check the Calendaring project 
at: 

http://osdl.org/projects/cmptblclndrng/results/

The real reason that there is no viable Open Source calendaring 
server is due mostly to the fact that the Internet Engineering 
Task Force hasn't finished the client/server protocol, known as 
the "Calendar Access Protocol" (CAP).

The data format for describing calendaring information exists 
(iCalendar: RFC2445), as well as how to communicate data between 
systems (iTIP: RFC2446), and how to use email as an iTIP message 
(iMIP: RFC2447).  These are very important formats that allow 
client software to interact.  In fact, many Open Source projects 
(e.g. Evolution) already implement these standards, but they lack 
the ability to talk to a central calendar repository, which would 
give them access to more advanced group calendaring capabilities.

With a central repository, many people can participate on the same 
set of events (delegation and resource scheduling), share 
free/busy data in one location, and feel safe knowing their data 
is getting backed up from one location.  Having a CAP is similar 
to having IMAP for email: the server manages all the folders, 
and the client is a view into the information.  CAP provides more 
than just a view, though, and any server implementing CAP would 
be in a position to offer even more functionality by the very fact 
that it has access to all the calendar data.  For example, event 
notifications (via email, paging, batch jobs, etc) could be handled 
from the central server.

Group calendaring is bound to become a major wish list item as
increasingly more organizations migrate their business services 
to Linux.  With the CAP draft close to becoming an RFC, the time 
is ripe for open source developers to tackle the need for a CAP 
daemon (icapd?) project.  Since the development of 
standards-compliant server daemons has been one of open source's 
greatest strengths, we're confident that anyone looking
for an open source solution to group calendaring faces only a 
short wait.

---

----- End forwarded message -----




More information about the Standards mailing list