The TurboChandler project is an exploration into providing an alternate HTML/AJAX-based UI for Chandler.

I'm keeping a log of my progress in TurboChandlerNotes

How?

Here are the basic instructions to get started. This assumes you have a working chandler checked out and that current directory the chandler directory:

> svn co http://svn.osafoundation.org/sandbox/alecf/parcels/turbochandler parcels/turbochandler
> svn co http://svn.osafoundation.org/sandbox/morgen/parcels/wsgiref wsgiref
> svn co http://svn.osafoundation.org/sandbox/morgen/parcels/twisted_wsgi twisted_wsgi
> release/easy_install -f http://www.turbogears.org/preview/download/index.html TurboGears

On windows, that last line is:

> release/RunPython release/easy_install-script.py -f http://www.turbogears.org/preview/download/index.html TurboGears

Now start chandler, and in the Test menu there should be an option "Start TurboChandler"

Run that and then go to http://localhost:1888/turbo-chandler/

Why?

The last few years have demonstrated that it is possible to build reasonably complex web-based applications very quickly. Further, the maturation of the browser market has allowed people to make very rich web experiences with what is now a very familiar environment of HTML and JavaScript.

We've really tried to push wx to create new, innovative UI but it has been very difficult and very time consuming. Most applications build on wx are very simple vertical market applications that don't demand a lot of complex user interaction. To make matters worse, the community of of wx "experts" is very small, at least relative to the rest of the Python community. (let alone the ever expanding web application developer communities!)

Until recently, rapid-development web frameworks were typically written in in Java (or C#) If we ever wanted to develop a web-oriented front end for chandler we'd have to do a lot of work ourselves to do it with Python. We'd be no better off than we are today with wxWidgets hand-rolling a lot of UI that other frameworks already have.

The recent confluence of events around Python web frameworks has brought Python into the fray as a legitimate contender for web applications. I found it really really interesting to talk with the folks at Merchant Circle at PyCon this year about how quickly they were able to build a complete, functional website using all Python ingredients (most of which are actually the components of TurboGears^?) They raved about how quickly they could develop their applications and I was jealous. Django and Zope developers are also similarly enthusiastic about their platforms.

And so I started TurboChandler. With 4-5 hours of work I had a really basic functioning sidebar and summary view. Another hour and I had a really rudamentary detail view.

Doesn't this compete with scooby?

Yes and no. Scooby is a web front end to a CalDAV/WebDAV server. This is a web front end to the Chandler repository.

Scooby provides access for anyone to access any account on a given server. TurboChandler provides access to exactly one user's repository.

It is actually possible that we might be able to reuse some of the Scooby front end code to create a calendaring experience for the user. Most of the infrastructure I'm creating is a sort of middleware for a basic chandler app, with a summary table and detail view.

Doesn't this compete with..well, chandler?

Yes and no. If anything it competes with the wxPython front end. But there is a lot to chandler besides the front end. You could imagine that instead of shipping a wx-based chandler, we could ship a web-based chandler with Firefox wrapping a frame around the main chandler UI.

Will you provide support for multiple users in a repository?

No. The goal here is to reuse as much of the existing chandler code as possible. All of that code is based on the assumption that all data in the repository belongs to the user. This means that all access into the repository is expected to get real user data.

What about XUL?

XUL is great but it has a much larger overhead and is not as python-centric as we'd like right now. There is hope in Mark Hammond's XUL/Python efforts that will probably be in Firefox 2.0. In the mean time, we can learn something about building an app based on a web framework.

How are you doing the front-end behavior? JavaScript or Python?

JavaScript runs within the browser and makes JSON calls to a headless chandler process running CherryPy. CherryPy acts as the go-between between the HTML and JavaScript that makes up the TurboChandler UI, and the rest of chandler.

Can I do this with a running Chandler?

Not right now, but I expect I'll have this running soon. Morgen has demonstrated to me that CherryPy can be embedded in Twisted, which is already running in an existing chandler process. I just need to hook it up. My hope is that soon using TurboChandler will simply be a matter of installing a parcel out of my sandbox.

How would one use this application? With a web browser?

While the particular experience of having to access some crazy http://localhost:12345/ URL inside firefox isn't great, one could imagine creating a very thin FireFox^?-based HTML renderer that access this local URL inside a native window frame that hides the URL and looks just like a normal, native-ish window. This could be as simple as a Firefox extension that may even be completely cross platform.

What do you expect to get out of this?

A few things:

1. A better understanding of how AJAX applications work. In the spirit of the kind of diversity that inspires innovation, (see "The Wisdom of Crowds") I think it is important that we explore other patterns of development that inspire us to solve problems and implement features in new ways.
2. A possible future for chandler after wxWidgets. Many of us who have been working on the Chandler front end have realized that there is a limit to what we can do with our current front end. The web is one alternative.