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

[Mark Cockfield]

Wow, this is great! I really appreciate all of the feedback.

Okay where to start?

I guess one of things that has me most excited after reading the various
CalDAV related RFCs, and finding them implemented in the Calendar Server is
interoperability. To my mind the biggest advantage is the ability of users
to access their schedules from as many points of access as possible. Their
workstations at work and home, any WiFi hotspot, web enabled devices, etc.
Then when I consider a scenario such as a user sitting in say a coffee shop
decides they want to schedule an appointment with their advisor that
afternoon, they go to the website and send an appointment...after checking
freebusy, how cool is that! The invitee while traveling from another
appointment receives a notification on their mobile device and accepts.
Another billable hour they would have missed if they had to wait to they got
their home or office. [Cyrus, a nod to you, Lisa, and the rest of the CalDAV
architects... phenomenal stuff!]

So for me, having a highly efficient repository on a server is essential.
Time range filtered reports will be the norm. I'm also looking at using the
"expand" option so I don't have the overhead of recurring events in the Flex
app. 

Then I start looking at maintenance, and bear in mind that the Calendar
Server data will only be a fraction of application data. Let's say there is
a problem with events having a certain set of attributes. In a database I
can run a SQL query and identify all of the affected records, and the fix
will just be another. New feature upgrades, add a column. Backing up all of
my application data is a very fast export. Let's say we want to consider
data replication, or other high-availability options.

Now, let's look at this from a "your data is an asset" perspective. Let's
say my client wants to create a report on when certain events with certain
attributes were scheduled, how about for specific users or users meeting
certain (domain) criteria. This would be a fairly straightforward SQL query.

Okay, scalability. Again, looking at all of the data involved most of which
will be in an RDBMS, I'm thinking in terms of clustered DB servers. I like
the way the front-end of the Calendar Server scales with the number of
processors and the use of PyDirector. Now your web/app and database servers
are two separately scalable tiers.

When I was looking at atomic commits I was thinking more about making sure
an event and all of its associated domain related data were a single
transaction.

Helge, you have offered some very compelling arguments for a file system
repository. Maybe I am being too heavily influenced by my own prejudice; I
remember the days when all we had were flat files and ISAM files, then DBMS,
and finally RDBMS. I'm also still in transition from a procedural to OOP
paradigm. But I look at my requirements and I'm still not convinced that in
the long run I wouldn't be better off in an RDBMS.

Also worth noting is that both the Chandler Server (Lisa's group) and
DAViCal both use a RDBMS, although I am curious about Chandler's storing the
entire iCal object in a single column.

Finally, I would be interested in hearing what Wilfredo's and David's
motivation was in creating their respective tickets regarding data
persistence.

Thanks again.

Mark