Web: The Brian Problem

Thinking back to the early days of Aquarium, Chuck Esterbrook and I thought about merging Aquarium and Webware. Unfortunately, I'm a bit of a code nazi, and Webware isn't the most minimal, style-conforming code around (which multiple people have confirmed, so it's not just me). This dissuaded me from joining forces. The fact that I was out of the Web world for about two years gave Webware a big leg up :-/

Moving forward, I'd like:

• To work hard on newbie documentation for the PyWebOff's concept of "Brian" (i.e. a Python newbie who knows PHP and is now trying to write Web applications in Python).


• To revive Piranha for all the "Ruby on Rails" folk. SQLObject and the Subway project may make some or all of this work unnecessary.


• To better integrate with SQLObject and FormEncode.


• To write a WebServerAdaptor for Twisted. At IronPort, we use coroutines. I work with Sam Rushing, the author of Medusa. Since coroutines are strictly better than Twisted (same benefits, but easier to code), if I can't support Twisted, I'm going to push harder for IronPort to open source its coroutines library and its version of stackless Python. This will be great since Aquarium's Web server, Glass, can already run in a coroutine environment.

There are many Web frameworks out there. Although reducing code duplication among them is a laudable goal (e.g. WSGI), I think having common things like Cheetah, SQLObject, FormEncode, etc. are great places to reuse code. However, having many Web frameworks reuse code doesn't really help "Brian". What we need for "Brian" is:

• Great beginner documentation.


• A larger community who agree on how Web applications should be developed.


• Mind share.

I think unifying the best parts and people from the Aquarium, Webware, CherryPy, Quixote, Subway, and Twisted community would be a great way to achieve this goal. Hence, I am approaching the "Brian" problem as a political one. The code is already there.