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ß" <me@helgehess.eu> 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