Я работаю на сайте PHP с базой данных пользователей и базой данных модераторов общего календаря (событий).
Я хочу опубликовать эти события в iCal / CalDAV, чтобы участники могли:
Приложение должно использовать сайт существующего пользователя & база данных календаря.
Я посмотрел на реализации CalDav в PHP & Python, все они кажутся слишком сложными для такого простого использования:
Как это сделать?
РЕДАКТИРОВАТЬ: Полезные ссылки для использования Sabre / DAV с существующей базой данных сайта:
РЕДАКТИРОВАТЬ: Улучшения:
Хотя Sabre / DAV работает как положено слишком медленно в создании серверное событие с приглашениями для ~ 100 местных жителей («принципалы»). И это генерирует 99x бесполезных копий события для каждого приглашенного. Обработка приглашений заняла около 8 секунд (более 30 секунд с включенным профилированием xdebug, и это привело к сбою!).
Что касается использования общий календарь, в стандарте есть только две возможности: либо дать приглашенному доступ для чтения-записи, чтобы он мог присоединиться к событию (но также изменить / удалить его!), либо предоставить ему доступ только для чтения … но он не может присоединиться к нему. Так что я играл с Sabre\CalDAV\Backend\PDO::updateCalendarObject()
ограничить редактирование события участником PARTSTAT
,
Но каким бы ни было решение, есть проблема с конфликты:
Когда участник А изменяет запись календаря, говоря, что он участвует (PARTSTAT ACCEPTED
), Sabre / DAV обрабатывает эту информацию путем обновления всех объектов календаря во всех пользовательских календарях. При этом SabreDAV увеличивает токен SYNC всех этих календарей.
Поэтому, когда участник B пытается присоединиться к событию, но не синхронизировал информацию о том, что участник A тем временем присоединился к событию, возникает конфликт, и информация о присоединении участника B ПОТЕРЯЛ.
Решение конфликта:
RFC 6638 определяет способ избежать таких конфликтов с помощьюschedule-tag
, Это только в дорожной карте Sabre / DAV для v3.3. Я разработал экспериментальную поддержку Sabre / DAV Вот но все же все Android-клиенты, которые я тестировал, не поддерживают этот RFC, только iOS! Во всяком случае, даже с schedule-tag
Если организатор изменит данные события или при использовании общих календарей, информация о каком-либо участнике будет потеряна.
Поэтому я сделал свою собственную реализацию Sabre / Dav, чтобы в большинстве случаев никогда не терять информацию о присоединении участников (кроме случаев, когда событие перенесено): Sabre / Dav PartsTat-Only-Calendar. По сути, он работает с учетом конфликтующего СОБЫТИЯ, отправленного пользователем, и записывает только информацию об участнике PARSTAT в событии сервера вместо обычного нажатия исключения PreconditionFailed. Мне все еще нужно опубликовать пример сценария запуска сервера, который использует все функциональные возможности.
(Вопрос кажется немного широким для StackOverflow.)
SabreDAV, кажется, является выбором при реализации сервера Cal / CardDAV в PHP. Скорее всего, имеет смысл использовать его.
а) Получить все события календаря, синхронно, с аутентификацией (частный URL …)
Ну, это должно быть покрыто.
б) Присоединиться к событию
Я предполагаю, что ваш вариант использования — это то, что у вас есть событие, но пользователь не был заранее приглашен на него. Но вы все еще хотите, чтобы пользователь «добавил» себя к событию.
Это не тот случай использования, который в настоящее время поддерживает стандарт CalDAV. В CalDAV есть общие календари и запланированные на стороне сервера события. Я думаю, что последний может работать для вас.
Вы можете синтезировать это поведение «добавить меня». Динамически добавлять пользователя в качестве участника к событию при представлении его клиенту. Затем он может принять / возможно / отрицать это. Если он это сделает, сохраните этот факт в главном событии — теперь он постоянный приглашенный.
в) (но не создавать или изменять событие)
Это поведение по умолчанию для запланированных событий сервера iTIP / CalDAV. Только ОРГАНИЗАТОР может изменять события, кроме таких вещей, как сигналы тревоги и т. Д.
Так что, похоже, подходит для вашего случая использования.
Других решений пока нет …