Introducing the thywill-python Asynchronous Messaging Framework
I recently pushed thywill-python out to Github for anyone who might find it interesting. This is a simple Python and Javascript framework that glues together a Comet server, a web server, and many client web browsers. Asynchronous messaging applications for web browsers that are built on top of thywill-python are written in Python (server-side) and Javascript (client-side). The thywill-python framework manages client browser connections and message delivery, so that the application author can focus on everything else.
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.
At the end of this prototyping and exploration exercise, I find that I now understand the space well enough to know that the best course ahead for this project is in fact to use node.js and work in Javascript rather than Python. Best laid plans and all that - but we should always build prototype code in the certain knowledge that there will be little of it left used by the time the project is done. One of the paths to that end is this one: to decide early on that you should be working in an entirely different language and framework.
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.
- thywill-python requires the use of both Python and Javascript, while a future thywill.js will require only Javascript. Python is a great language, but the number of people who know it well is substantially lower than the number of people who know Javascript well.
- 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.
These points largely feed into the questions of later adoption: how easy will it be for people to understand, set up, and use thywill? These are important things to consider when building a framework, and it is clearly the case that a thywill.js will be a lot easier on a hypothetical later developer than thywill-python. Thus my next step is to reframe the work accomplished to date in Javascript using node.js and socket.io, which should be a fairly rapid process now have a much better grasp on the core architecture that I need to establish.