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

Helge Heß me at helgehess.eu
Wed Oct 15 14:47:38 PDT 2008

On 15.10.2008, at 23:23, Mark Cockfield wrote:
> This application that I'm developing needs to be highly scalable. I  
> already
> had a sense of trepidation regarding a file system data store

Using files is super scalable and efficient if the majority of the  
access is retrieving the files as-is. Which is the case in WebDAV. If  
you HTTP GET the iCal/vCard resources, the application does not even  
need to touch the files, the kernel can directly serve the files from  
disk to network. Using a database is magnitudes slower in such a  

> when I
> discovered ticket #s 198 and 269 and was relieved to find I'm not  
> alone. I'm
> wondering how much thought has been given to this issue? Wilfredo  
> talked
> about separate repositories either for calender or calendar/home and  
> I'm
> assuming Sqlite would be the DBMS? My vision is of a single database  
> (like
> Andrew Mcmillan's DAViCal, in either Postgres or MySQL) as calendar  
> data is
> going to be one small facet of the application data model and this  
> strikes
> me as a desirable approach from a performance, scalability,  
> maintenance
> perspective...I think.

If you prefer using a database backend for everything instead of plain  
files, you could take a look at ScalableOGo. Its a combination between  
raw-content storage and structured SQL tables (but then CalServer is  

Well, and if you just want a regular groupware backend, w/o a specific  
iCalendar focus, you could look at OpenGroupware.org, eGroupware, ...

Actually I think you haven't told us yet, what your application is  
supposed to do. So its hard to give suggestions on the path ... There  
are something like 400+ groupware servers listed on Freshmeat, one of  
them should be a good starting point ;-)

Helge Hess

More information about the calendarserver-dev mailing list