I thought I'd... discuss these two frameworks. I don't have any conclusions or summaries or explanations. History?

Anyway, a while back I was working on CherryPaste and I got frustrated with CherryPy. There were problems with CherryPy's WSGI support, and some design changes that just seemed obvious to me -- mostly internal refactorings I wanted to see happen so that CherryPaste could call functions that were a bit more explicit about what was happening, with no singletons and no injection.

I think at that point I was doing some more bitching and whining on #pythonpaste, and Julian Krause was on there too and was feeling a bit annoyed with CherryPy at the time as well (actually about sessions if I remember correctly, a now-resolved problem which is unrelated to anything else here). And he brought up the idea of reimplementing. Or maybe I did. Anyway, so we reimplemented it; he moved over the URL parsing, I set up the package using Paste, and after about a day or two we had a pretty reasonable framework. Frameworks can be really easy to write (and I wrote that document in part because the framework came out so easily and it seemed like a good example). And we searched around for names -- I like Rhubarb Pie, a search on "Rhubarb Python" came up with this, and the name seemed just perfect.

So, what is RhubarbTart? It is functionally pretty much equivalent to CherryPy. That is, it feels similar to work with, the APIs match CherryPy's as much as possible, and all the same features are available. Most of those features actually came from other places, they aren't implemented in RhubarbTart, and that's part of the point as well. The core feature is that RhubarbTart makes a request object, does some URL path parsing, and does a function call and gets a response. It also interacts nicely with WSGI applications, which you can put anywhere in your tree. All the other features are just wrappers coming from elsewhere.

The one thing RT is missing is CherryPy's filters, and there aren't any plans to implement those. CP's filters are kind of complicated, and backward compatibility is hard, and some of the features they implement are a little weird to use in filter form -- like serving static files. Why you don't say static = StaticFiles(directory) in CherryPy, I don't really understand. I've also seen lots of concern about performance, and in my own experience with CherryPaste (which uses filters) the failure cases are confusing.

RhubarbTart will probably be getting somewhat larger, in that more URL resolution schemes will be added, Routes in particular. We also brainstormed some ideas at the PyCon sprint about adding flexibility. I think what we came up with is going to be a lot more general and workable than what you'll see in most other frameworks (like Quixote, Zope, etc). Instead of magic methods and complex overrides, there's just one override -- stop here, aka __call__ or respond. If you want to capture some information then continue parsing, then you capture and call the parser. All sorts of features fall out of this easily, more than traversal hooks offer.

But after that... I don't see any reason for RhubarbTart to get larger. Getting back to sessions, Julian wasn't really happy with Paste Sessions (probably for good reason), and created a Myghty session WSGI middleware. But it's not part of RhubarbTart. Once RT's small number of features are fully worked out -- which shouldn't take too long -- I expect it to become a very boring and stable piece of software. Already Ben Bangert is looking at whether Pylons can be built on RT, and we have TurboGears on it in a branch.

At the same time RhubarbTart may be getting smaller. We're probably going to move the request object out to Paste, with a subclass in RhubarbTart that adds a few CherryPyisms. I've been reluctant to add any request object to Paste in the past -- it seemed like it was too framework-specific -- but this time around it feels much better to me. Ben has put up some code in paste.request.

Now, back to CherryPy. Since the time of my frustration there have been several improvements with its WSGI support. There's also talk of a CherryPy 3. I really don't know how the two will continue to relate. There was some reluctance to embrace WSGI whole-heartedly. I think this is a bad idea -- supporting WSGI as one-among-many backends is not very sensible, it's just more code. I had a similar reaction from Django developers at one time too, where they didn't want to use a particular piece of WSGI middleware because they supported a WSGI and a mod_python frontend (despite the fact the whole concept was impossible under mod_python anyway -- not to mention that you can make a mod_python WSGI server easily enough).

But I digress. So, what if CherryPy is simplified in version 3? I'm not sure if they will be simplified towards what RhubarbTart is doing or not; in particular, there is a strong tendency to make traversal hooks instead of making traversal easy to reapply. If CP 3 does become like RhubarbTart, I'm not sure what the point of the distinction will be. Except, I suppose, that they are developed by a different set of people. If that happens, then even though they don't have any shared code lineage at this time they'll effectively be forks. I don't think that's a huge problem, but it's a funny place to be in.