Greetings, I am developing an RIA in Flex which needs to be built upon a calendaring foundation. After discovering that the CalendarServer is the Holy Grail I have not only found my foundation, but a good part of my infrastructure as well. Really nice work! Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods. After considerable thrashing about I seem to be faced with the following two options: 1. Code my own HTTP client in Actionscript at the socket level. 2. Use PyAMF and the Twisted Gateway to hook a Remote Messaging interface into the Calendar Service. As I don't really relish the thought of #1, and though I'm still fairly early in the Python/Twisted/PyAMF/CalendarServer learning curve, I think #2 might have some merit. The current line of reasoning is that in cluster.py where the memccahed and notification processes are being added to monitor a twisted gateway process could be added as well. Then in tap.py, after site = Site(realRoot), "site" could be added to the gateway as the remote object to call...? The idea being that you would simply send HTTP requsts in an array through the AMF channel to the appropriate method on the server. So what I'm hoping for is that someone might be able to tell me I am either out of my mind, or better yet, on the right track. Any thoughts would be greatly appreciated. Mark
On 04.09.2008, at 23:34, Mark Cockfield wrote:
Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods.
One option might be to enhance Twisted to support the X-HTTP-Method- Override header: http://www.pluralsight.com/community/blogs/dbox/archive/2007/01/16/45725.asp... http://code.google.com/apis/gdata/basics.html#Updating-an-entry Not sure whether such a patch would be accepted, but IMHO its not the worst idea. Greets, Helge -- Helge Hess http://zideone.com/
Le 08-09-05 à 01:51, Helge Heß a écrit :
On 04.09.2008, at 23:34, Mark Cockfield wrote:
Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods.
One option might be to enhance Twisted to support the X-HTTP-Method- Override header:
http://www.pluralsight.com/community/blogs/dbox/archive/2007/01/16/45725.asp...
http://code.google.com/apis/gdata/basics.html#Updating-an-entry
Not sure whether such a patch would be accepted, but IMHO its not the worst idea.
Another solution would be to have a 3 tier approach, where the Flex app will contact a server-side app (by POST and GET methods), which in turns will contact the CalDAV server.
Hi Mark, --On September 4, 2008 5:34:20 PM -0400 Mark Cockfield <mark.cockfield@gmail.com> wrote:
I am developing an RIA in Flex which needs to be built upon a calendaring foundation. After discovering that the CalendarServer is the Holy Grail I have not only found my foundation, but a good part of my infrastructure as well. Really nice work!
A little Google'ing indicates that the RIA in Flex seems very limited.
Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods.
Apparently you can do a little more than that with their proxy service: <http://livedocs.adobe.com/flex/2/langref/mx/rpc/http/HTTPService.html> However, you really need to be able to do PROPFIND (and possibly PROPPATCH) and REPORT to work well with CalDAV, so that probably doesn't help.
After considerable thrashing about I seem to be faced with the following two options:
1. Code my own HTTP client in Actionscript at the socket level.
2. Use PyAMF and the Twisted Gateway to hook a Remote Messaging interface into the Calendar Service.
Helge's suggestion of using X-HTTP-Method-Override is probably your best choice. I am not sure whether we could support such an option. It probably wouldn't be that big a change. The alternative is to use a proxy that understands that header and turns the request into the "real" one as it passes through to the real server. I would strongly urge you to file a ticket against RIA/Flex asking for arbitrary HTTP method support. It seems silly not to provide that when workarounds such as X-HTTP-Method-Override, and more importantly when more web services are using "richer" WebDAV protocol elements. -- Cyrus Daboo
Helge, Cyrus, Pascal, I really appreciate the feedback. The broad issue here seems to be that the RIA domain apparently has relegated HTTP to basic content retrieval and is favoring protocols such as AMF and JSON for data management. WebDAV does not seem to be on their radar. At first I thought this was just a knee-jerk reaction by Adobe to some nefarious activity that was conducted with version 7 of the Flash Player allowing cross-site scripting...I believe that was the problem anyway. But it seems that even Microsoft with Silverlight has reverted back from the full HTTP vocabulary that was supported in the earlier versions to now supporting only GET and POST as well. I'm not sure where OpenLaszlo is on the matter, but both Microsoft and Adobe have been petitioned quite vociferously for full HTTP support and both seem to be remaining steadfast in their positions. The two arguments I have come across are that many HTTP stacks don't support the full vocabulary and that many firewalls block the extended methods. So whether this is silly, I would almost go so far as to say inconceivable, this is the current reality. And whether RIAs are going to be the wave of the future remains to be seen; but the technology seems to be gathering significant momentum and at the moment does provide the most pleasing browser based user experience. Then there is the small matter of a recent investment in the Flex development tools.... As it is quite obvious that the Calendar Server stands head-and-shoulders above the other offerings, I am highly motivated to make this work! Helge, Intriguing idea. Unfortunately the HTTP response header is also unavailable (in Actionscript), they really seem to be insistent on their designs for the use of HTTP. Pascal and Cyrus, the proxy approach crossed my mind too. It seems to me the two obvious approaches to an adapter are: 1. A process on the server that consumes the AMF request and then sends an HTTP request to the Calendar Server. Since I don't have access to the response header, I need the header and body in and out of the server to be in the body of the message in and out of the Flex client. 2. PyAMF's Twisted Gateway which appears to have been developed to address this issue. This would result in a variation on POST Tunneling, as I understand it, but the adapter would be natively plugged into the Calendar Server's Twisted architecture. Which to my thinking is the less complicated approach, but does require exposing the Calendar Service as a remote object to be called. Which if my understanding is correct is basically what happens when the HTTP request hits the server and the callable site object is invoked. Well, as nobody has indicated I am out of my mind, I am going to explore this a bit further. Cyrus, if this does prove to be a viable approach, is it something you would be interested in? Thanks again for the feedback, Mark On 9/5/08 9:39 AM, "Cyrus Daboo" <cdaboo@apple.com> wrote:
Hi Mark,
--On September 4, 2008 5:34:20 PM -0400 Mark Cockfield <mark.cockfield@gmail.com> wrote:
I am developing an RIA in Flex which needs to be built upon a calendaring foundation. After discovering that the CalendarServer is the Holy Grail I have not only found my foundation, but a good part of my infrastructure as well. Really nice work!
A little Google'ing indicates that the RIA in Flex seems very limited.
Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods.
Apparently you can do a little more than that with their proxy service:
<http://livedocs.adobe.com/flex/2/langref/mx/rpc/http/HTTPService.html>
However, you really need to be able to do PROPFIND (and possibly PROPPATCH) and REPORT to work well with CalDAV, so that probably doesn't help.
After considerable thrashing about I seem to be faced with the following two options:
1. Code my own HTTP client in Actionscript at the socket level.
2. Use PyAMF and the Twisted Gateway to hook a Remote Messaging interface into the Calendar Service.
Helge's suggestion of using X-HTTP-Method-Override is probably your best choice. I am not sure whether we could support such an option. It probably wouldn't be that big a change. The alternative is to use a proxy that understands that header and turns the request into the "real" one as it passes through to the real server.
I would strongly urge you to file a ticket against RIA/Flex asking for arbitrary HTTP method support. It seems silly not to provide that when workarounds such as X-HTTP-Method-Override, and more importantly when more web services are using "richer" WebDAV protocol elements.
I thought I would share my findings incase others venture down this path. After finally getting the Calendar Server running within the Eclipse IDE PyDEV debugger it soon became obvious that plan "A" was not going to work without a bit of kludging. I think it may have been possible to get the Twisted Gateway to call the site object; however it would also have required cobbling together an HTTPChannel request object as one of the arguments of the site call. Then after exploring the socket approach a bit: implementing digest authentication, connection maintenance, etc., etc., still not appealing. So it looks like having the Twisted Gateway call an HTTP client on the server side to send a proper request to the Calendar Server is going to be the most straight forward approach. I was hoping to avoid a middleware scenario, but I don't think I have a choice, and it does open up some options as well. Now for my next issue/thought/fit of insanity... This application that I'm developing needs to be highly scalable. I already had a sense of trepidation regarding a file system data store 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. So I guess I'm looking to see what thought has transpired in this realm, what the priority is within the development team, and if there is any overlap in objectives can we coordinate to minimize duplication of effort? Regards, Mark Helge, Cyrus, Pascal, ...Helge, Intriguing idea. Unfortunately the HTTP response header is also unavailable (in Actionscript), they really seem to be insistent on their designs for the use of HTTP. Pascal and Cyrus, the proxy approach crossed my mind too. It seems to me the two obvious approaches to an adapter are: 1. A process on the server that consumes the AMF request and then sends an HTTP request to the Calendar Server. Since I don't have access to the response header, I need the header and body in and out of the server to be in the body of the message in and out of the Flex client. 2. PyAMF's Twisted Gateway which appears to have been developed to address this issue. This would result in a variation on POST Tunneling, as I understand it, but the adapter would be natively plugged into the Calendar Server's Twisted architecture. Which to my thinking is the less complicated approach, but does require exposing the Calendar Service as a remote object to be called. Which if my understanding is correct is basically what happens when the HTTP request hits the server and the callable site object is invoked. Well, as nobody has indicated I am out of my mind, I am going to explore this a bit further. Cyrus, if this does prove to be a viable approach, is it something you would be interested in? Thanks again for the feedback, Mark On 9/5/08 9:39 AM, "Cyrus Daboo" <cdaboo@apple.com> wrote:
Hi Mark,
--On September 4, 2008 5:34:20 PM -0400 Mark Cockfield <mark.cockfield@gmail.com> wrote:
I am developing an RIA in Flex which needs to be built upon a calendaring foundation. After discovering that the CalendarServer is the Holy Grail I have not only found my foundation, but a good part of my infrastructure as well. Really nice work!
A little Google'ing indicates that the RIA in Flex seems very limited.
Now imagine my disappointment upon realizing that Actionscript has been apparently locked down to only allow GET and POST http methods.
Apparently you can do a little more than that with their proxy service:
<http://livedocs.adobe.com/flex/2/langref/mx/rpc/http/HTTPService.html>
However, you really need to be able to do PROPFIND (and possibly PROPPATCH) and REPORT to work well with CalDAV, so that probably doesn't help.
After considerable thrashing about I seem to be faced with the following two options:
1. Code my own HTTP client in Actionscript at the socket level.
2. Use PyAMF and the Twisted Gateway to hook a Remote Messaging interface into the Calendar Service.
Helge's suggestion of using X-HTTP-Method-Override is probably your best choice. I am not sure whether we could support such an option. It probably wouldn't be that big a change. The alternative is to use a proxy that understands that header and turns the request into the "real" one as it passes through to the real server.
I would strongly urge you to file a ticket against RIA/Flex asking for arbitrary HTTP method support. It seems silly not to provide that when workarounds such as X-HTTP-Method-Override, and more importantly when more web services are using "richer" WebDAV protocol elements.
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 -- Helge Hess http://helgehess.eu/
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
On 16.10.2008, at 08:53, Mark Cockfield wrote:
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.
You keep repeating that, but w/o saying why? :-) Its much easier to deal with a million individual files than with one super fat database. Just consider the FS a database.
Then I started wondering about the scalability of time range filtered reports and performance in general.
OK. First you seem to mix scalability (how easy you can grow, how much you can grow) with performance. Of course they are related, but different. Consider a calendar collection. You could (and many 'traditional' servers do) store all events of all users in a single SQL table. This works fine up to a certain count, maybe ~10.000.000 records to give a very rough figure. This gives you space for very good performance for just 1000 users with 10.000 events each. Afterwards you will need to work increasingly harder to actually scale the database. The system does not scale well beyond this point (though it has great performance below that point). Contrast that with CalServer. It stores the structured data per server, each in its own (SQLite3) database. Queries across different calendars are slower because multiple databases need to be touched. BUT you can easily add more databases, hence the system scales very well (in fact w/ super high limits in number of calendars). But more importantely, keep in mind that the primary consumers of the CalServer are calendaring clients. iCal, Outlook, Thunderbird etc. Those clients always synchronize full calendars with their local cache. And run queries/reports *inside* that cache. Hence the server is optimized to deliver the raw data quickly to the clients. Which then do the actual work. Well, and this works best with plain files. Now either you also do the work in the client or your middleware, or you use a backend which is optimized for queries instead of content delivery :-)
I was also thinking that atomic commits would be an important design requirement
You probably refer to the ability to commit multiple events in a single transaction? Thats indeed not possible with CalDAV/CalServer. [Obviously a single PUT in CalServer *is* atomic :-)] Anyways, a customized SOGo server might deal with your requirements best. You could enhance the SOGo index tables to contain the additional information you need to query (your X- attrs) and you could add transactions (as long as you limit scalability and keep related calendars in a single database, which is possible with SOGo). Still you get good iCal/vCard interop. Have fun, Helge -- Helge Hess http://helgehess.eu/
Hello Helge, You've done a really good job selling the file-system approach :-) And I do believe you're correct most cases. But like Mark I was surprised when I first found that FS was used over a database in calendar server.
Contrast that with CalServer. It stores the structured data per server, each in its own (SQLite3) database. Queries across different
I can easily be wrong but that may be more of an attempt to work around SQLite's lack of table or row level locking rather than a deliberate database access optimization. That's SQLite's official workaround for the issue and SQLite more than nudges you in that direction when considering it in your designs.
But more importantely, keep in mind that the primary consumers of the CalServer are calendaring clients. iCal, Outlook, Thunderbird etc. Those clients always synchronize full calendars with their local cache. And run queries/reports *inside* that cache. Hence the server
It seemed to me that a major design goal for CalDAV was to move as much processing as possible to the server, away from the client. The server has to provide the same CalDAV query/report features even if older calendar clients rely more heavily on their own local cache. PS. My predication is that we're eventually going to see the single database datastore supported. Best regards, Kervin
On 16.10.2008, at 18:47, Kervin Pierre wrote:
Contrast that with CalServer. It stores the structured data per server, each in its own (SQLite3) database. Queries across different I can easily be wrong but that may be more of an attempt to work around SQLite's lack of table or row level locking rather than a deliberate database access optimization.
Can't tell what Cyrus motivation was, but in ScalableOGo we also support per-folder tables for precisely that reason. In a 60.000 user installation your rarely query all user calendars, but usually just a small subset. Being able to split up the query engines gives much better scalability.
But more importantely, keep in mind that the primary consumers of the CalServer are calendaring clients. iCal, Outlook, Thunderbird etc. Those clients always synchronize full calendars with their local cache. And run queries/reports *inside* that cache. Hence the server It seemed to me that a major design goal for CalDAV was to move as much processing as possible to the server, away from the client.
Yes, and (obviously?) that doesn't make a lot of sense given that one of the biggest features of native clients is the offline capability! :-) Plus scalability, since you distribute the workload among C x S machines instead of just S. Plus speed, just local IO for queries. etc etc In other words: How many IMAP4 native clients actually use IMAP4 search or MIME decoding facilities? Those who do, are they faster in offline mode or online mode? ;-)
PS. My predication is that we're eventually going to see the single database datastore supported.
Sure, why not. In ScalableOGo I did this because web interface was a key part and additional middleware is just so much slower than directly querying the same store. Greets, Helge -- Helge Hess http://helgehess.eu/
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
On Oct 16, 2008, at 8:50 PM, Mark Cockfield wrote:
Finally, I would be interested in hearing what Wilfredo's and David's motivation was in creating their respective tickets regarding data persistence.
I added couple of comments to http://trac.calendarserver.org/ticket/198 . Atomicity is my greatest concern at the moment. http://trac.calendarserver.org/ticket/269 is important regardless of whether we use a DB or not. We have some administrative functions that we'd like to be able to implement without running a server or instantiating HTTP resources and doing HTTP things to them. The data model and protocol are inter-twined right now, and that's just poor abstraction. -wsv
Hi Wilfredo, Thanks for the reply. Yep, reporting makes me shudder. I may look at the possibility of loading the file system store into the application database when I need to create reports. If the calendar object properties are separate columns, the possibilities become interesting. I hadn't really considered atomicity from just a calendar store perspective, very valid point. And since your repository is comprised of discrete entities, cleanup become challenging. I was hoping, and I'm not completely convinced that it is hopeless, that I could make application and Calendar Server updates atomic. It seems to me that since I am planning on adding my PyAMF Twisted gateway as a caldav pluggin and will be using SQLALchemy and PostgreSQL, that there should be a way to handle the SQLA database sessions and nested transactions to theoretically pull it off. So for meetings are you thinking of an audit trail? Would each attendee have a copy of the master? By edits to you mean counter proposals or personal descriptions and comments? Ticket #269 was actually the first to catch my eye, left me with foreboding regarding RDBMS, then I hit #198 and #132...okay all is not lost. Another thought that has been kicking at the back of my head is MVC. A more loosely coupled architecture would have benefited me on the the view side as it would facilitate integrating emerging technologies in the client domain. Strip out the HTTP protocol and you are left with a command syntax: method is your command, header and body become arguments. So I guess a questions becomes: does the CalDAV standard require a tight binding to a specific protocol? Although, it seems to me the Twisted architecture does. On the model side, SQLAlchemy allows me switch between a SQLite memory database and several flavors of RDBMS by changing one line of config. Then a question here becomes: is it worth maintaining a file system option in the abstraction? Regards, Mark On 10/28/08 2:37 PM, "Wilfredo Sánchez Vega" <wsanchez@wsanchez.net> wrote:
On Oct 16, 2008, at 8:50 PM, Mark Cockfield wrote:
Finally, I would be interested in hearing what Wilfredo's and David's motivation was in creating their respective tickets regarding data persistence.
I added couple of comments to http://trac.calendarserver.org/ticket/198 .
Atomicity is my greatest concern at the moment.
http://trac.calendarserver.org/ticket/269 is important regardless of whether we use a DB or not. We have some administrative functions that we'd like to be able to implement without running a server or instantiating HTTP resources and doing HTTP things to them. The data model and protocol are inter-twined right now, and that's just poor abstraction.
-wsv
Hi Helge, --On October 16, 2008 9:41:13 AM +0200 Helge Heß <me@helgehess.eu> wrote:
But more importantely, keep in mind that the primary consumers of the CalServer are calendaring clients. iCal, Outlook, Thunderbird etc. Those clients always synchronize full calendars with their local cache. And run queries/reports *inside* that cache. Hence the server is optimized to deliver the raw data quickly to the clients. Which then do the actual work. Well, and this works best with plain files.
Don't forget thin clients or web clients which may have little or no cache. I know several groups working on web-based solutions and they nearly always use the time-range reporting capability of CalDAV to retrieve just the events they need for display purposes. Our current strategy does deal with that reasonably efficiently in that time-range queries are handled via an sqlite DB for each calendar. -- Cyrus Daboo
On 16.10.2008, at 18:55, Cyrus Daboo wrote:
Don't forget thin clients or web clients which may have little or no cache. I know several groups working on web-based solutions and they nearly always use the time-range reporting capability of CalDAV to retrieve just the events they need for display purposes. Our current strategy does deal with that reasonably efficiently in that time- range queries are handled via an sqlite DB for each calendar.
Well, IMHO this isn't the best idea, really :-) Even for a webapps the speed will be magnitudes better if they sync changes to a 'local' (middleware) cache and work on top of that. Running a SQL query against an RDBMS is (very) much faster than doing a REPORT via HTTP. Best of all, it works with GroupDAV servers too! (eg plain mod_dav) ;-) Greets, Helge PS: I still think it would be pretty nice if a webapp could directly use the SQLite structures of CalServer. Somewhat similiar to SOGo. -- Helge Hess http://helgehess.eu/
participants (6)
-
Cyrus Daboo
-
Helge Heß
-
Kervin Pierre
-
Mark Cockfield
-
Pascal Robert
-
Wilfredo Sánchez Vega