CalendarServer: Difference between revisions

From Traxel Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:OpenDevOps]]
[[Category:OpenDevOps]]


= Protocol: DAV, iCal, ICS, CalDav =
= Servers =


Answer: CalDav, from: https://stackoverflow.com/questions/30048720/whats-the-difference-between-webcal-and-webdav-caldav
https://www.linux.com/training-tutorials/five-best-open-source-calendar-servers-linux/
<blockquote style="background-color: #EEEEEE; border: solid thin grey;">
 
All what Julian said, but presumably the real question is about the difference between plain iCalendar-over-HTTP (commonly called webcal, 'iCalendar subscription' or 'subscribed calendar') and CalDAV. Or in other words: what does CalDAV add.
== Darwin Calendar Server ==
 
Built at Apple and fully Open Source. Supports calendaring, tasks, and contacts. Requires mount-time filesystem permissions, which may be difficult on an inexpensive hosted server - we'll see.
 
https://www.calendarserver.org/
 
==  DAViCal ==
 
Supports calendar and contacts. GPL, which is a plus. Backed by Postgres instead of the filesystem, which appeals to me as an old-school RDBMS person.
 
https://www.davical.org/


Simply put: in iCoHTTP you usually store a whole calendar under one URL, like 'http://yahoo.com/sports/nba/schedule-2015.ics' (or webcal:). This URL represents a full calendar and is almost always readonly (you can't do a PUT to this URL). Why is that? Because to add/change/delete a single event in such a calendar, you would need to re-transfer the full calendar.
== Bedework ==


In CalDAV a calendar is a WebDAV collection, there is one URL which represents the calendar, e.g.: 'http://icloud.com/calendars/joe/home/' and then you have one child URL for each event. Like 'http://icloud.com/calendars/joe/home/buy-beer.ics', 'http://icloud.com/calendars/joe/home/family-meeting.ics' and so on. You can then just DELETE, PUT etc individual items of such a collection.
This looks like the Emacs / Swiss Army Knife of calendar servers. "...written in Java, and designed to run on the Apache Tomcat application server. In addition, it requires JBoss, Apache Directory Server (DS), Derby, ActiveMQ, and Ant."


In summary: If you simply want to publish a calendar which rarely changes and is managed by other means (like a CMS), you can use iCal-over-HTTP. If you want to provide a calendar which the user (or maybe a group of people) can change from within their calendar client, you want to use CalDAV.
Includes a web front-end and RSS feed, which sounds really nice. Seems like the high operational expense would require justification (which the ample features might supply).


CalDAV also has a set of extensions, e.g. many CalDAV server can automatically perform scheduling operations for you (setting up meetings and such). There is an extension to share calendars with other people, and so on.
Built by a company (Apereo) that really talks the talk of Open Source.


P.S.: This is a bit confusing, but yes, Apple also has a way of using WebDAV to manage iCalendar subscriptions. But this is yet another thing which works alongside CalDAV.
https://www.bedework.org/
</blockquote>


= Clients =
= Clients =
Line 37: Line 46:


https://f-droid.org/en/packages/at.bitfire.davdroid/
https://f-droid.org/en/packages/at.bitfire.davdroid/
= Protocol Choice: DAV, iCal, ICS, CalDav =
An early question in this investigation, simply answered and recorded here as an artifact, was what protocol to use, given I had only a vague notion of what was out there.
Answer: CalDav, from: https://stackoverflow.com/questions/30048720/whats-the-difference-between-webcal-and-webdav-caldav
<blockquote style="background-color: #EEEEEE; border: solid thin grey;">
All what Julian said, but presumably the real question is about the difference between plain iCalendar-over-HTTP (commonly called webcal, 'iCalendar subscription' or 'subscribed calendar') and CalDAV. Or in other words: what does CalDAV add.
Simply put: in iCoHTTP you usually store a whole calendar under one URL, like 'http://yahoo.com/sports/nba/schedule-2015.ics' (or webcal:). This URL represents a full calendar and is almost always readonly (you can't do a PUT to this URL). Why is that? Because to add/change/delete a single event in such a calendar, you would need to re-transfer the full calendar.
In CalDAV a calendar is a WebDAV collection, there is one URL which represents the calendar, e.g.: 'http://icloud.com/calendars/joe/home/' and then you have one child URL for each event. Like 'http://icloud.com/calendars/joe/home/buy-beer.ics', 'http://icloud.com/calendars/joe/home/family-meeting.ics' and so on. You can then just DELETE, PUT etc individual items of such a collection.
In summary: If you simply want to publish a calendar which rarely changes and is managed by other means (like a CMS), you can use iCal-over-HTTP. If you want to provide a calendar which the user (or maybe a group of people) can change from within their calendar client, you want to use CalDAV.
CalDAV also has a set of extensions, e.g. many CalDAV server can automatically perform scheduling operations for you (setting up meetings and such). There is an extension to share calendars with other people, and so on.
P.S.: This is a bit confusing, but yes, Apple also has a way of using WebDAV to manage iCalendar subscriptions. But this is yet another thing which works alongside CalDAV.
</blockquote>

Latest revision as of 16:09, 10 November 2021


Servers

https://www.linux.com/training-tutorials/five-best-open-source-calendar-servers-linux/

Darwin Calendar Server

Built at Apple and fully Open Source. Supports calendaring, tasks, and contacts. Requires mount-time filesystem permissions, which may be difficult on an inexpensive hosted server - we'll see.

https://www.calendarserver.org/

DAViCal

Supports calendar and contacts. GPL, which is a plus. Backed by Postgres instead of the filesystem, which appeals to me as an old-school RDBMS person.

https://www.davical.org/

Bedework

This looks like the Emacs / Swiss Army Knife of calendar servers. "...written in Java, and designed to run on the Apache Tomcat application server. In addition, it requires JBoss, Apache Directory Server (DS), Derby, ActiveMQ, and Ant."

Includes a web front-end and RSS feed, which sounds really nice. Seems like the high operational expense would require justification (which the ample features might supply).

Built by a company (Apereo) that really talks the talk of Open Source.

https://www.bedework.org/

Clients

Simple Calendar Pro

Calendar client (I know, obviously, right? But there are also task list clients for CalDAV - see next)

https://f-droid.org/en/packages/com.simplemobiletools.calendar.pro/

Tasks.org

Task client that seems extremely powerful so far. Supports tags, lists, and subtasks. Date specification is a bit weak, but it's supposed to be a task list, not a scheduling app. and I think it integrates with calendars as well, so finer grained date control might be do-able via a calendar app.

https://f-droid.org/en/packages/org.tasks/

DAVx5

CalDAV synchronizer

https://f-droid.org/en/packages/at.bitfire.davdroid/

Protocol Choice: DAV, iCal, ICS, CalDav

An early question in this investigation, simply answered and recorded here as an artifact, was what protocol to use, given I had only a vague notion of what was out there.

Answer: CalDav, from: https://stackoverflow.com/questions/30048720/whats-the-difference-between-webcal-and-webdav-caldav

All what Julian said, but presumably the real question is about the difference between plain iCalendar-over-HTTP (commonly called webcal, 'iCalendar subscription' or 'subscribed calendar') and CalDAV. Or in other words: what does CalDAV add.

Simply put: in iCoHTTP you usually store a whole calendar under one URL, like 'http://yahoo.com/sports/nba/schedule-2015.ics' (or webcal:). This URL represents a full calendar and is almost always readonly (you can't do a PUT to this URL). Why is that? Because to add/change/delete a single event in such a calendar, you would need to re-transfer the full calendar.

In CalDAV a calendar is a WebDAV collection, there is one URL which represents the calendar, e.g.: 'http://icloud.com/calendars/joe/home/' and then you have one child URL for each event. Like 'http://icloud.com/calendars/joe/home/buy-beer.ics', 'http://icloud.com/calendars/joe/home/family-meeting.ics' and so on. You can then just DELETE, PUT etc individual items of such a collection.

In summary: If you simply want to publish a calendar which rarely changes and is managed by other means (like a CMS), you can use iCal-over-HTTP. If you want to provide a calendar which the user (or maybe a group of people) can change from within their calendar client, you want to use CalDAV.

CalDAV also has a set of extensions, e.g. many CalDAV server can automatically perform scheduling operations for you (setting up meetings and such). There is an extension to share calendars with other people, and so on.

P.S.: This is a bit confusing, but yes, Apple also has a way of using WebDAV to manage iCalendar subscriptions. But this is yet another thing which works alongside CalDAV.