[CalendarServer-dev] Hoping for a sanity check: Chapter 2
me at helgehess.eu
Thu Oct 16 10:11:10 PDT 2008
On 16.10.2008, at 18:47, Kervin Pierre wrote:
>> 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.
Can't tell what Cyrus motivation was, but in ScalableOGo we also
support per-folder tables for precisely that reason. In a 60.000 user
installation your rarely query all user calendars, but usually just a
small subset. Being able to split up the query engines gives much
>> 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.
Yes, and (obviously?) that doesn't make a lot of sense given that one
of the biggest features of native clients is the offline capability! :-)
Plus scalability, since you distribute the workload among C x S
machines instead of just S.
Plus speed, just local IO for queries.
In other words: How many IMAP4 native clients actually use IMAP4
search or MIME decoding facilities? Those who do, are they faster in
offline mode or online mode? ;-)
> PS. My predication is that we're eventually
> going to see the single database datastore
Sure, why not. In ScalableOGo I did this because web interface was a
key part and additional middleware is just so much slower than
directly querying the same store.
More information about the calendarserver-dev