Hello Helge, You've done a really good job selling the file-system approach :-) And I do believe you're correct most cases. But like Mark I was surprised when I first found that FS was used over a database in calendar server.
Contrast that with CalServer. It stores the structured data per server, each in its own (SQLite3) database. Queries across different
I can easily be wrong but that may be more of an attempt to work around SQLite's lack of table or row level locking rather than a deliberate database access optimization. That's SQLite's official workaround for the issue and SQLite more than nudges you in that direction when considering it in your designs.
But more importantely, keep in mind that the primary consumers of the CalServer are calendaring clients. iCal, Outlook, Thunderbird etc. Those clients always synchronize full calendars with their local cache. And run queries/reports *inside* that cache. Hence the server
It seemed to me that a major design goal for CalDAV was to move as much processing as possible to the server, away from the client. The server has to provide the same CalDAV query/report features even if older calendar clients rely more heavily on their own local cache. PS. My predication is that we're eventually going to see the single database datastore supported. Best regards, Kervin