[CalendarServer-dev] Hoping for a sanity check: Chapter 2

[Kervin Pierre]

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