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

[Mark Cockfield]

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 at 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