test specification online ics icalshare ical example java icalendar caldav

java - specification - Desarrollando un servidor CalDav



ics editor (2)

Déjame intentarlo ;-)

¿Cuáles son los pasos generales?

Como lo mencionó Evert, debe implementar un servidor CalDAV. Dependiendo de las funciones que desee admitir, esto no es trivial y requiere la comprensión de las especificaciones relevantes (iCalendar RFC 5545 y CalDAV 4791, WebDAV RFC 4918).

¿Cuáles son los pasos generales para implementar un servidor CalDAV? Necesita puntos de entrada HTTP para:

a) Servir la información de la cuenta (llamada principales en WebDAV), esto incluye bajo qué URL viven los calendarios de una cuenta

b) sirva la lista de calendarios (llamada la página principal del calendario, la información principal de a) apunta a esto)

c) Servir los calendarios reales, es decir, los eventos contenidos dentro de esos. Los calendarios CalDAV son colecciones especiales de recursos de "iCalendar" de WebDAV. iCalendar es el formato en el que se representan los eventos.

Dependiendo de las características de CalDAV que desee admitir, esto puede ser mucho más complejo (por ejemplo, la programación del lado del servidor). Hay optimizaciones para sincronizaciones más rápidas (informes de sincronización), o subidas, etc. No necesita todo para comenzar.

¿Necesito ofrecer un servlet? En caso afirmativo, ¿qué debo devolver para una solicitud? ¿Un archivo JSON o XML o .ics?

Como dice Evert, la forma en que implementa los puntos finales HTTP es su elección. Los servlets son una opción viable. La información principal, las listas de calendario y las URL de los elementos dentro de un calendario se devuelven en XML (WebDAV) (respuestas de varios estados). El contenido real de un evento debe devolverse en el formato iCalendar (.ics).

Cuando un usuario se suscribe a mi calendario, significa que su cliente retirará mi servidor (llame al servlet) después de un intervalo.

Sí.

Algunas implementaciones de CalDAV también son compatibles con Push (donde el servidor puede decirle al cliente cuándo hay nuevos datos disponibles), pero aún no está estandarizado y las implementaciones varían mucho. El sondeo se puede mantener rápido si su servidor implementa CTags e informes de sincronización (RFC 6578).

Tengo un conjunto de eventos guardados en mi base de datos (una base de datos muy especial, por lo que no puedo usar algunos servidores populares de código abierto con, por ejemplo, MySQL). Ahora quiero construir un servidor CalDav (por Java) para que un usuario pueda conectar su cliente de calendario para recuperar o modificar eventos. Soy nuevo en esto, así que tengo muchas preguntas, espero que me ayuden.

  1. ¿Cuáles son los pasos generales?

  2. ¿Necesito ofrecer un servlet? En caso afirmativo, ¿qué debo devolver para una solicitud? ¿Un archivo JSON o XML o .ics?

  3. Cuando un usuario se suscribe a mi calendario, significa que su cliente retirará mi servidor (llame al servlet) después de un intervalo.

Actualización: esta es una pregunta de 1 año desde la primera vez que hice la pregunta, pero obtuve algunos upvotes, por lo que estoy obligado a proporcionar algo de información: terminé usando la biblioteca de Milton http://milton.io/ , se abstrae de los servlets , solo hay que escribir funciones para devolver datos. El autor de la biblioteca es bastante útil e informativo. El resultado final: nuestro servidor caldav ha funcionado.

También acepto la respuesta de Evert.


Lea el RFC: http://tools.ietf.org/html/rfc4791

No solo una vez, quieres al menos leerlo de arriba a abajo 4 veces.

Más que eso, probablemente debería leer también los RFC para WebDAV, WebDAV ACL y iCalendar.

Cualquier respuesta que obtendría aquí sería una repetición de lo que hay allí, y tratar de simplificar esto es bastante inútil, porque realmente necesita una comprensión completa de la mayoría de las especificaciones.

Para responder a sus preguntas específicamente:

  1. Es demasiado vago para responder. Los pasos generales implicarían comprender la especificación y escribir el servidor. Los detalles son alentados.
  2. Necesita algo que pueda responder a las solicitudes HTTP. Si eso es un servlet o algo más es menos importante. CalDAV es una extensión para HTTP. Los informes XML se devuelven para metainformación, e iCalendar es el formato predeterminado para los datos reales del calendario. Para muchas solicitudes http, iCalendar está envuelto en cuerpos xml. Estos días los servidores también están empezando a soportar xCal y jCal. Los dos últimos son opcionales, debes tener soporte iCalendar.
  3. Por lo general, sondearán en un intervalo definido por el cliente. Existen mecanismos de publicación sub, pero actualmente no hay un estándar para ellos, y existen varias implementaciones. Las discusiones han comenzado a idear un transporte estándar para esto, pero esto puede tomar algún tiempo en completarse. (años)