Hi Helge, Thanks for the feedback.
The application, which I am developing for a client and therefore need to discuss in general terms, will basically be coordinating activities in a mentoring type of an environment. Each event will have fairly involved domain specific attributes and logic linked to it by "X-" iCalendar attributes pointing to records in a relational database. The Calendar Server scheduling, notification, and interoperability will be critical features, and really provide all of the groupware functionality I require. The bulk of the application will be the unique domain functionality that I will have to build on top of it. Let me preface my thoughts by saying that I have not spent much time exploring the Calendar Server data model, other than what I have gleaned from the RFCs, and am only attempting to open a dialog at this point because of the two tickets relating, very closely, to my own initial thoughts. My initial thought is that if the number users grows into the thousands a file system based repository could become unwieldy thus resulting in maintenance/management issues. Then I started wondering about the scalability of time range filtered reports and performance in general. I was also thinking that atomic commits would be an important design requirement, but I seem to be moving away from that possibility. Anyway, now that I have a better vision on the front-end, I am hoping to bring the back-end into focus. Regards, Mark On 10/15/08 5:47 PM, "Helge Heß" <[EMAIL PROTECTED]> wrote: > 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 > scenario. > >> 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 > too). > > 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 ;-) > > Greets, > Helge _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
