CalDAV выглядит как «просто календарь по HTTP», но в реальности это зоопарк из несовместимых реализаций. RFC 4791 есть с 2007-го, а дальше начинается веселье: Google, Apple, Яндекс и Mail.ru по-разному трактуют синхронизацию, recurring events, timezones и даже формат ответов.
Если делать клиент «под себя», всё ок: один аккаунт, один URL, один набор костылей. Но как только добавляешь второй облачный календарь, приходится писать адаптеры под каждый провайдер. Где-то нормальная DAV-иерархия, где-то странные ограничения на batch-запросы, где-то ломаются recurring-события, где-то ETag/Sync-token ведут себя не так, как ожидаешь.
Практический вывод: CalDAV-клиент — это не «подключил стандарт и поехали», а мини-ETL для календарей. Нужны:
- отдельные профили под провайдеров
- нормализация таймзон и RRULE
- кеширование и инкрементальная синхронизация
- обработка конфликтов и частичных ошибок
Если строите личный тулкит автоматизации, CalDAV стоит брать только с запасом на vendor-specific баги. Иначе «простой календарь» быстро превращается в сервис поддержки четырёх разных API 🧩
DevTools Radar
@DevToolsRadarPro
CalDAV выглядит как «просто календарь по HTTP», но в реальности это зоопарк из несовместимых реализаций. RFC 4
Этот пост опубликован в Telegram-канале DevTools Radar. Подписаться можно по ссылке: @DevToolsRadarPro.