Happy to see OAuth support for CalDAV. Still sad that it's always going to be saddled with legacy vCalendar issues.
Both CalDAV and CardDAV suffer from their history and badly need redesigning. Not much has changed in the 10 years since I was hacking on libical. I mean, consider the following CDATA chunk from the RFC. No one should need to parse/generate this ancient format. It's complicated, finicky and plain awful.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060206T001102Z
DTSTART;TZID=US/Eastern:20060102T100000
DURATION:PT1H
SUMMARY:Event #1
Description:Go Steelers!
END:VEVENT
END:VCALENDAR
Maybe I should standardize SnmpDav? At least it has XER which would make it slot into XML without the ugliness above.
In any case I hope that a new calendaring standard emerges from this muck that is more developer friendly.





A couple more pull quotes:
"... at Etsy. We instead want to view mistakes, errors, slips, lapses, etc. with a perspective of learning. Having blameless Post-Mortems on outages and accidents are part of that."
"an engineer who thinks they’re going to be reprimanded are disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure. "
"A funny thing happens when engineers make mistakes and feel safe when giving details about it: they are not only willing to be held accountable, they are also enthusiastic in helping the rest of the company avoid the same error in the future."
Ed S, Jun 03 2013 on 1500wordmtu.com