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/