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

[Helge Heß]

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  
better scalability.

>> 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.
etc etc

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
> supported.

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.

Greets,
   Helge
-- 
Helge Hess
http://helgehess.eu/