first CalDAV Plone Improvement Proposal (PLIP)

Definitions

(Focus on links offered by CalConnect, The Calendaring and Scheduling Consortium …)

Motivation

Plone 3.0.3 offers download of iCal (.ics) and vCal (.vcs) files.

Whist visitors to a site may use an .ics download as their initial source of information regarding an event, we should not assume that users (even those with a great interest in an event) will periodically revisit that page of the Plone site to learn of possible changes to an event. 

It is more likely that users of .ics compatible client software (Apple iCal, Mulberry, Mozilla Lightning for Thunderbird, Mozilla Sunbird, Evolution et cetera) will simply 

1. download the .ics then 
2. rightly or wrongly, treat their 'desktop' calendar software (not a Plone site) as their handy/definitive source of information. 

iCalendar publish/subscribe, webcal:// protocol, should be an improvement over simple .ics download. 

However, without wishing to detract from ongoing development of iCalendar-oriented servers: 

Assumptions

CalDAV, and related standards, at acceptable levels of maturity. 

Acceptable levels of interoperability between relevant CalDAV servers from multiple vendors. 

If Python and Zope expertise is common to both (a) Plone and (b) Darwin Calendar Server, then Darwin Calendar Server  may be a good starting point. Other CalDAV server implementations may be equally valuable.  

Chandler Hub (an implementation of Chandler Server (Cosmo)) bears the distinction of offering event-oriented Atom feeds, which may be useful for comparative testing (result of Atom feed alongside result of CalDAV). Other CalDAV implementations may distinguish themselves in equally valuable ways. 

Proposal

See links to discussions etc., suggestions are welcome. 

As there is a 14th December 2007 deadline in relation to the Plone 3.1 timeline: 

• consider the possibility of phased proposals, phased implementations
• from this fairly unrestrained draft of a first proposal, we may distil aspects that are more suitable for a second, then transfer a draft to the plone.org area for PLIPs
• through Plone's filtered list of PLIPs that are deferred or rejected, we may view comments that guide us regarding suitability of proposals in general. 

Implementation

As above, suggestions are welcome. 

Realism

Consider the following:

• first and foremost, strict decision making for PLIPs
• Official Internet Protocol Standards include 2445 and 4791
• CalDAV Scheduling Extensions to WebDAV  is in (fine) draft state
• in CalConnect's October 2006 glossary of calendaring and scheduling terms CalDAV is defined by two specifications; if this glossary definition is still correct then one of the two is draft, not official
• issues such as http://chandlerproject.org/Projects/KnownIssues#Interaction and http://trac.calendarserver.org/projects/calendarserver/report/1

Orderly, not rushed. Decide upon aspects/approaches that will be most acceptable and realistic for PLIPs…

• back to basics including http://dev.plone.org/plone/ticket/7336#comment:1 notions (1) and (2)
• for some things we may take an installable non-core product approach
• have things working to our satisfaction to form the basis of a PLIP
  
• and so on.

Source code

Questions from a newcomer: 

• Is code relating to a PLIP developed within a Trac at plone.org?
• If so, are related privileges granted only if a PLIP is successful? 

Deliverables

As above, suggestions are welcome. 

Risks

…

Progress log

Draft PLIP at Google Docs: Friday 30th November 2007. 

e-mail from Graham Perrin to Jeff Kowalczyk (author of the February 2005 post): Friday 30th November 2007. 

Draft PLIP scraped from Google Docs, copied to this site, thanks to Cris Ewing: Friday 30th November 2007. 

Participants 

PLIP drafting process

PLIP submission