Thursday, July 26, 2007

Looking Forward To Wasp 2.0

WaspWasp needs to be significantly rejigged before I'll release it. Times have changed; Python has gained a lot of functionality in seven years, and people expect more from a web application framework. This article will outline what I hope to do to improve Wasp.

Wasp currently works in two modes: as a command-line batch processor and as a CGI application. The first of these is fairly uncommon in WAPs, but of great utility. Many times I have used the simple templating together with a few custom functions to produce HTML documentation as static files that I can throw on a server or disk.

I want to preserve both these modes and add a third: a threaded web server with Wasp embedded. This will make it easy to test web applications on the desktop. And maybe it'll be robust enough for production use, perhaps even out-performing the CGI mode. I'm going to ensure this outputs a detailed log in standard format, unlike the Python library modules for same.

Perhaps an obvious addition would be a mode to allow WSGI compatibility. But I'm not going to bother, at least not for the version 2.0 release, because I think WSGI apps serve a different niche. And there's already plenty of them out there.

I need to do a major code cleanup, removing obvious warts, refactoring the modules and stripping away useless libraries... even some that are not entirely useless but just not core enough. Here I'm going to be quite ruthless. My forms handling module will be going as there are other, likely better, approaches out there. So too the data buffer module. People can use SQLAlchemy (though I'll not enforce a choice).

The configuration file module will be removed, as I'm going to change the syntax of the Wasp configuration file to plain Python code. That's just more elegant and the syntax is no harder to understand. However I'm keeping my date and cookie modules because I like them better than the standard libraries.

By the way, Wasp 2.0 will require Python 2.5, because I can't be bothered remembering what features I'm not allowed to use to make it compatible with earlier versions. This version has been around since September 2006, so I hope most people have updated by now.

Error handling needs to be enhanced. I like how easy it is to debug web app errors, but more can be done, I am sure. Useless info needs to be removed from some of the error dumps. And I will add a local variable listing.

User modules will be renamed "plugins" and it'll be even easier to use them. Currently they need to be listed in the configuration file, but I want them to be automatically recognised based on the fact they are in the plugin folder. And automatically reloaded as they change, of course. Not needing to stop the web server for dynamic user changes will be a big productivity boost.

The application-level modules, those not strictly necessary to run Wasp, need to be so indicated through nomenclature. If there was greater integrity between the modules, and enhanced app functionality out of the box, that would be nice. How about ready-made blogging tools? Yes, I'll start there, but target version 2.1 for that functionality.

Finally, the templating needs to be enhanced. I'll write more on that subject anon.

I've always been rather good about writing documentation, but I need to make the presentation of same clearer and prettier.

And more unit tests. And a document test suite that will exercise Wasp server functionality.

That likely sounds like an awful lot of work. Certainly it means that this Wasp will be significantly unlike its predecessor... hence the jump to version 2.0. The tags and configuration files will not be backwards compatible, so in addition to everything else I will need conversion utilities to ease the upgrade pain.

Maybe you are by now thinking that this is all pie in the sky. But here's the good news: Most of the work is already done!

It's just that I'm very tardy writing my blog articles. Bonus!

RELATED POSTS

No comments:

Post a Comment