Split caldav PROPFIND ответ, когда он слишком большой

Question

У меня есть встроенная реализация CalDAV, которая нормально работает нормально, но с одной проблемой. Есть клиенты с сотнями календарей, которые синхронизируются по мобильной сети. Каждый раз, когда iCalendar запрашивает PROPFIND с глубиной = 1, мой сервер должен ответить полным списком календарей, дающих огромный ответ, который иногда не получается из-за нестабильной мобильной сети.

Я думаю, что ответ разделения на более мелкие куски (например, 30 за ответ) поможет, но я не знаю, действительно ли это возможно.

Итак, вопрос: могу ли я принудительно подключить клиент к календарю PROPFIND в последовательных запросах кусками N календарей?

Answer 1

Нет, для этого нет согласованного стандарта.

Это, как говорится: (1) вы сжимаете ответ? (2) посмотрели ли вы http://tools.ietf.org/html/draft-murchison-webdav-prefer-05?

Answer 2

Когда вы говорите «100-ые календари», вы имеете в виду «100 событий»? Потому что ответ PROPFIND с 100 пунктами фактически не большой, это совершенно нормально. Но довольно часто список событий в календаре может быть большим. Но Apple обычно делает неплохие клиенты Caldav, и они должны делать запросы REPORT с соответствующим диапазоном дат, чтобы они не получали слишком много событий.

Возможно, ваш сервер Caldav не реализует весь спектр отчетов, поэтому клиент возвращается к более простому подходу.

Answer 3

Как уже упоминалось, brad необходимо различать количество календарей и количество событий в календаре.

Наличие сотен календарей очень необычно, но это должно быть любопытно. PROPFIND с 100 результатами не слишком большой. Также обратите внимание на CTag, если это доступно, вы знаете, нужно ли вам сначала синхронизировать содержимое календаря.

Скорее всего, вы действительно спрашиваете о некоторых календарях, содержащих много событий, может быть тысячи. В таких случаях PROPFIND: 1 в календаре, чтобы захватить ETags для проверки изменений, может стать большим & медленным. (в любом случае убедитесь, что вы поддерживаете Accept-Encoding: gzip и Brief: T).

Для этого случая есть RFC'd-решение: RFC 6578. С синхроническими отчетами вам нужно вернуть записи, которые были изменены с момента последней синхронизации. Он поддерживается iOS и iCal. Спецификация также поддерживает пакетную обработку (называемую усечением в RFC), но это не реализовано для всех клиентов.