Как выставить адресные книги CardDAV/календари CalDAV с произвольными фильтрами?

Я хочу предоставить доступ к адресным книгам и календарям, к которым могут применяться поисковые фильтры (например, теги, пользователи, группы).

Они не должны обнаруживаться автоматически, потому что могут быть миллиарды комбинаций, но, тем не менее, должны быть совместимы с распространенными клиентами (например, iOS / OS X, Windows Phone), т. е. должна быть возможность добавить URL-адрес с фильтрами к клиенту.

Одна проблема заключается в том, что некоторые клиенты полагаются на функции обнаружения, а не на URL-адрес, который вы им даете, например. iOS (вы пытаетесь добавить одну адресную книгу по точному URL-адресу, и вместо этого добавляются все доступные для обнаружения).

Еще одна вещь — структурирование дополнительных фильтров.
А как насчет использования путей?
Что здесь считается передовой практикой?


filter caldav carddav sabredav
person Arc    schedule 15.04.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Календари доступны только для чтения или для чтения? Если они доступны только для чтения, вы можете использовать веб-URL-адреса для календарей (так называемые «подписные календари» или iCalendar-over-HTTP).

Для календарей Cal/CardDAV устройства Apple (и большинство других клиентов DAV) настраивают полную учетную запись (используя обычные механизмы обнаружения учетных записей), а не только «URL-адрес». Я не думаю, что есть способ обойти это.

Предполагая, что вы создаете веб-службу, которая предоставляет реестр/поисковую систему или которая является агрегатором таких данных календаря или адресов, эта служба может затем предоставить учетные записи Cal/CardDAV (которые реализуют обнаружение).

В вашем веб-сервисе у вас будет два варианта:

  1. прокси (и, возможно, кеширование) удаленных данных
  2. создайте «подписной календарь CalDAV» (специальный ресурс WebDAV, который указывает на календарь CalDAV (тип ресурса {http://calendarserver.org/ns/}подписался)).

Для контактов у вас есть только выбор 1. И в качестве дополнительной сложности вы можете выставить сохраненные запросы как группы vCard вместо коллекций CardDAV. Это связано с тем, что некоторые клиенты (например, некоторые приложения MacOS Contacts) поддерживают только одну коллекцию CardDAV (и используют только группы для структурирования данных).

Образец: Допустим, вы изобрели сервис под названием «Caloogle.com». Пользователю необходимо получить какую-либо учетную запись в этой службе (может быть создана автоматически и т. д.). Пользователь добавляет учетную запись CalDAV на свое устройство iOS (например, используя предварительно настроенный профиль, чтобы ему не нужно было вводить все данные), которое затем подключается к Caloogle для извлечения данных в базу данных iOS EventKit. Теперь в вашем приложении Caloogle (или на веб-сайте) вы позволяете пользователю искать данные календаря. Если пользователь нашел набор, который ему нравится, он сохраняет его в виде календаря в Caloogle, скажем, «Даты выпуска дивидендов BP, Apple и AlwaysRightInstitute». iOS в конце концов пропингует учетную запись и подберет сохраненный календарь. Пользователь поражен и счастлив.

То, как вы на самом деле реализуете веб-службу (прокси или сопоставление имени и URL-адреса), во многом зависит от того, откуда поступают ваши данные...

Имеет смысл?

P.S.: Будьте осторожны при хранении запросов в URL-адресах, некоторые компоненты инфраструктуры HTTP имеют ограничения на длину URL-адреса, и расширенные запросы могут быстро переполнить его.

person hnh    schedule 15.04.2015
comment
Хорошо, спасибо, то, что я подозревал... так что я думаю, что единственный хороший обходной путь - это открыть виртуальный сервер DAV, чтобы фильтры были закодированы в пути, и передать их серверу, чтобы он работал везде. . Например. http://server/user:john/tags:acme+denver/ откроет весь виртуальный подсервер с принципалами, CardDAV и/или CalDAV. Для поиска с закладками/избранного (как в вашем примере) я мог бы выставить их под сервером DAV по умолчанию http://server (используя .well-known). Календари и контакты доступны для чтения/записи. - person Arc; 15.04.2015
comment
Я не могу понять все, что вы говорите, но да, ваш интерфейс на стороне сервера должен быть сервером CalDAV, чтобы иметь возможность подключаться к клиенту CalDAV ;-) С принципалами и всем прочим. Я не уверен, почему вы говорите, что 'server/user:john/tags:acme+ denver выставит весь виртуальный подсервер с принципалами». Это звучит неправильно, вы определенно не хотите создавать одну учетную запись CalDAV для каждого поиска? - person hnh; 15.04.2015
comment
Я имею в виду, что я бы использовал переписывание URL-адресов веб-сервера, чтобы предоставить полную конечную точку sabre/dav с возможностью обнаружения по нескольким URL-адресам, например. http://server/user:john/ сам по себе будет URL-адресом CalDAV/CardDAV, ниже которого вы найдете основную информацию, календари и адресные книги. - person Arc; 15.04.2015
comment
Относительно коллекций: законно ли выставлять один и тот же объект vCard/vEvent/... (с одним и тем же UID) в нескольких коллекциях или обязательно присваивать каждой из них разные UID? - person Arc; 15.04.2015
comment
По-прежнему не могу следить за вами по URL-адресу, но это нормально :-) Просто убедитесь, что вы не создаете одну учетную запись для каждого запроса, пользователи вас возненавидят :-) - person hnh; 15.04.2015
comment
Да, вы можете поместить один и тот же UID в разные коллекции, что разрешено в Cal/CardDAV. Хотя я думаю, стоит отметить, что некоторые серверы запрещают это (на разных уровнях, например, iCloud разрешает несколько экземпляров для незапланированных ресурсов, но требует уникальности сервера для запланированных), но это не должно влиять на вас. - person hnh; 15.04.2015

arrow_upward
0
arrow_downward

Как сказал hnh в его ответ интеллектуальные клиенты будут пытаться обнаружить предлагаемые вами службы DAV при настройке CardDAV или CalDAV по URL-адресу, а не просто использовать этот URL-адрес, поэтому, похоже, нет простого способа предоставить несколько виртуальных коллекций, отфильтрованных по тегам. , пользователи, группы и т. д.

Самое простое решение, которое могло бы сработать, — предоставить один виртуальный сервер DAV для каждого URL-адреса фильтра с полным обнаружением службы в рамках ограничений этого URL-адреса фильтра.

Виртуальные конечные точки предоставляются с помощью перезаписи URL-адресов, функции, имеющейся на обычных веб-серверах, и все они будут указывать на одну и ту же кодовую базу сервера DAV и снабжать ее критериями фильтрации.

Если, например, вам нужны коллекции элементов CalDAV/CardDAV с тегами PR и Spain, вы можете выставить их под https://dav.server/tag:PR/tag:Spain/, а элементы с тегом China можно выставить под https://dav.server/tag:China/.

Обратите внимание, что каждый URL-адрес обеспечивает полную функциональность DAV с возможностью обнаружения. Поскольку обнаружение относится к соответствующим корням https://dav.server/tag:PR/tag:Spain/ и https://dav.server/tag:China/, интерференции не будет.

Кроме того, вы можете предоставить простой URL-адрес https://server для четко определенного набора коллекций CalDAV / CardDAV, например. календарь/адресная книга по умолчанию или некоторые «закладки» коллекций, определенных пользователем каким-либо образом, например. «PR Испания».

Затем простой URL-адрес будет обеспечивать эти перенаправления HTTP в соответствии с RFC 5785:

https://server/.well-known/caldav    =>    https://dav.server/default
https://server/.well-known/carddav   =>    https://dav.server/default

Клиенты iOS и те, которые поддерживают общеизвестные URI, затем можно было настроить, просто установив хост на server и указав учетные данные для входа.
Затем они попытались бы подключиться через HTTPS, проверить общеизвестные URI и, таким образом, обнаружить конечную точку DAV. в 11_.

Тем, у кого нет общеизвестной поддержки URI или обнаружения, потребуется точный URL-адрес, например. https://dav.server/default/calendars/jane/main или https://dav.server/tag:China/calendars/jane/main.

person Arc    schedule 15.04.2015