Introducing the thywill-python Asynchronous Messaging Framework
The best way to learn a new language or a new application space is to prototype an application. My current slowly developing side-project has the long term aim of building a framework for a type of game that I feel hasn't been well explored over the past decade or two, using modern web browsers as the gaming platform. That is the top of the pyramid, at least. Down at the bottom of that structure can be found such things as browser-based asynchronous messaging frameworks: game code running on a browser must be able to receive server-initiated messages in real time.
Pushing server-initiated messages to a browser over HTTP is an interesting problem, of course. Outside of such things as Flash, embedded Java, and so forth, the general class of solutions are known as Comet servers, which are something of a bridging technology on the way to browsers and web protocols that natively support real TCP sockets (or at least something that looks a lot like a real TCP socket). In essence, HTTP can be stretched and hacked into something that can support more or less real time delivery of server-initiated messages to present day browsers, and in ways that won't flatten a server that has many clients presently connected.
But back to thywill-python, which is the end result of the prototyping exercise I ran while exploring the space of Comet servers and messaging applications. Since I was learning, why not learn a new language and a new web application framework while I was at it? Hence Python, and hence the fact that thywill-python uses Django. Since I was using Python, I picked Orbited as a comet server - though as it turns out, the fact that Orbited is written in Python isn't all that important in this context.
The structure of thywill-python, and how it acts in practice, is probably best illustrated by the following diagrams. They show the bootstrap process that occurs when a client browser connects to the running thywill-python server:
I built thywill-python in a modular fashion, knowing that since this was a prototyping exercise it was very likely that at least some of the initial technology choices would change. So Orbited, Django, the database and logging mechanism can easily be swapped out when that change does happen. The core of thywill-python is nothing more than configuration, component abstraction layers, and data routing, structured so that any of the component interfaces can be replaced with a minimum of fuss.
Why thywill.js on node.js rather than thywill-python using Python?
- It requires fewer distinct server applications to achieve the same end, which makes a big difference in the complexity of setting up a thywill server. The role of Orbited and Django in thywill-python are replaced by packaged node.js library code in thywill.js.
- It is next to trivial to produce simple asynchronous messaging applications in node.js: the support for this usage is excellent and baked into the libraries at a very fundamental level.