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/ _______________________________________________ calendarserver-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
