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

Mark Cockfield mark.cockfield at gmail.com
Wed Oct 15 14:23:52 PDT 2008

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?



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

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,


On 9/5/08 9:39 AM, "Cyrus Daboo" <cdaboo at apple.com> wrote:

> Hi Mark,
> --On September 4, 2008 5:34:20 PM -0400 Mark Cockfield
> <mark.cockfield at 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.

More information about the calendarserver-dev mailing list