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