[cosmo-dev] caldav<-->chandler model

[Randy Letness]

Ok I'm realizing that mapping date info from VTODOs to Chandler's 
EventStamp isn't as straight forward as I thought.  The problem is that 
EventStamps on the server are represented as VEVENTs.  So I thought it 
would be easy to map a VTODOs event information into VEVENT and 
vice-versa.  Well, its close because I thought:

VTODO:DTSTART -> VEVENT:DTSTART
VTODO:DUE -> VEVENT:DTEND
VTODO:DURATION -> VEVENT:DURATION
VTODO:RRULE,EXRULE,RDATE,EXDATE -> VEVENT:RRULE,EXRULE,RDATE,EXDATE
VTODO:LOCATION ->VEVENT:LOCATION

Seems logical, except according to rfc-2445, VEVENT start and end dates 
must be the same type, that is if DTSTART is a date, then DTEND must 
also be a date.  There are no nuch restrictions on VTODOs, and it just 
so happens that ical 3 creates VTODOS that look like:

BEGIN:VTODO
PRIORITY:0
SEQUENCE:3
DTSTART;TZID=US/Central:20040101T120000
UID:441CBEE0-DF72-4C6C-B6C1-5B2AAED298E5
DTSTAMP:20080522T161403Z
SUMMARY:task
CREATED:20080522T161330Z
X-APPLE-SORT-ORDER:2147483647
DUE;VALUE=DATE:20080522
END:VTODO

That is DTSTART is a date/time and DUE is a date.  This doesn't map at 
all to a VEVENT.

Also, STATUS doesn't map because the possible values are different for 
VEVENT and VTODO.

So I propose we don't translate the event data in a VTODO into an 
EventStamp because its just going to cause problems.  Instead we 
continue to store the VTODO so that we can interop with caldav clients 
and if an event stamp is added using Chandler, the item becomes a 
VEVENT.   Plus, the code is considerably less complex and I would be 
more comfortable with this solution for 1.0.

So the mapping looks like:

new VEVENT--> NoteItem with EventStamp
new VTODO --> NoteItem
new VJOURNAL --> NoteItem

NoteItem with EventStamp --> VEVENT
NoteItem with EventStamp and TaskStamp -0> VEVENT with X-OSAF-STARRED
NoteItem with TaskStamp only --> VTODO with X-OSAF-STARRED
NoteItem with no stamps --> VTODO


-Randy