WebSocket, js.io and replacing Comet

The prototype of my web-based game client uses Comet for the client-server communication. Recently, I have encountered more and more articles about WebSocket. As it is a cleaner and simpler way of doing what Comet does, I decided to look into the feasibility of adopting it now.

The options

Using WebSockets is not an option at this time. They are not supported to a level which makes them a viable solution, and only bleeding edge versions of the major browsers currently have the required support.

However, there is another possibility. That is, to use a solution which emulates the WebSocket interface as a layer over Comet. I've stumbled across two candidates in my browsing, the first being Kaazing Gateway, and the second js.io. I imagined that adopting one of these, or something similar, would enable me to write cleaner, simpler code that was future proof.

Possible solutions

I can write off Kaazing Gateway immediately. As a commercial product with a large download, the cost of adopting it is immediately higher than I am willing to pay. While it may suit the needs it was designed for, for my needs, there is no reason that the code required should not be lightweight and minimal.

js.io sounded much more promising. However, as a project, it is in a state where its usage is opaque and unclear to interested parties like myself. There is no documentation and the web site refers the user to the source code. It turns out that it both does and does not provides what I am looking for, but the latter aspect was also partly based on my lack of comprehension about the full range of functionality provided by WebSockets.

Researching js.io

Ideally, I wanted a client-side script that simply wrapped the Comet functionality, and allowed it to be used through a WebSocket interface. At least until using WebSocket itself became a viable option. Despite descriptions I had read of js.io painting it as something resembling this, I was unable to find anything within the existing browsable source code which looked suitable.

However, one of the many web searches I did found an older obsoleted script. It turns out that the earlier version of js.io provides exactly what I am looking for. Well, almost.

The earlier version of js.io layers on top of other solutions which provide a required TCPSocket object, specifically Lightstreamer and Sprocket. The default implementation of TCPSocket, which js.io falls back on looking for, is the one provided by Orbited. Unfortunately, these solutions are servers and frameworks, which are too heavyweight to be suitable for my needs.

What next?

Gutting Orbited is one option, but then I am effectively forking it, and the onus is on me to keep an eye on fixes and changes its maintainers make. Probably the best choice at this stage is to stick with Comet.

Documentation for Stackless Python

Stackless Python hasn't had proper documentation. Anyone wanting to use it has had to glean the information they needed from a range of sources, including:

• The mailing list.
• Example code that has been written for it, much by me, including my widely used stacklesssocket.py library.
• The tutorial that was written for it by Grant Olson.

As I volunteer a lot of time and effort towards doing required tasks for Stackless, anything that no-one else has been willing to do, by default stands out as something I need to try and find time for myself.

Recently, I have been wanting to work on some personal projects and unfortunately, Stackless' need for documentation is something I am always aware of. In order to be able to better concentrate on my personal projects, I resolved to bite the bullet and write the documentation, to get it out of the way.

After a week and a bit of work, I have finally finished working on the initial release of documentation for Stackless. As it is late at night here, and I need to call it a night, I have not checked it in or uploaded it to stackless.com yet, but you can see the mirrored files on my web site.

If you find this of use, or for that matter, anything else I have worked on, like the stacklesssocket.py module. Then please consider donating something.

Reverse engineering Amiga software

When I was young I had to walk to school, and it was ten miles both ways, in bare feet, always raining, with snow coming at me sideways on gravel roads. Oh, and everything was a lot more interesting then, because nostalgia hadn't been invented yet.

Living in New Zealand, television shows and movies made their way over here quite a while after they had debuted wherever they originated from. And so did computer games of course. Unfortunately, the only way to get access to software in a manner that didn't require a lifestyle consisting of yacht ownership, smoking jacket wearing or coke sniffing through one hundred dollar bills, was buying pirated disks through the mail.

Reverse engineering

One of the most interesting parts of the pirated software, was the material added by the groups which had originally pirated it. Take for example this video taken from the first disk of Pools of Darkness.

The Amiga console supported an extended range of ANSI commands, some of which allowed moving the cursor an arbitrary number of pixels. By printing a character, then moving the cursor so the next printed character would overwrite some of the last, and repeating this, an image could be rendered in the console. The slow rendering of the image is also a nice effect.

There was one commercial disassembler available for the Amiga, named ReSource. Like IDA Pro, it is an interactive disassembler, an environment where code can be progressively reverse engineered over time.

Here's a screenshot of the SKID_ROW program disassembled in ReSource:

Interestingly, the slow rendering effect is the maximum speed of the console, as the screenshot shows that the complete text to be displayed is written to the console as one lump.

A wiki

In any case, there's a wealth of interesting material preserved from the early days of the Amiga when it was still a contender. If you share my interest in examining it, the most convenient way to do so is by running WinUAE, and perhaps running ReSource within that. But there is also domain knowledge in the tip and tricks to being able to access some of the data, and also what tools can be used in which ways.

I suggested that it would be nice to collect this knowledge on a forum and someone responded by suggesting I start a wiki on one of those sites that are around these days. On a whim, I decided to do so, but in order to make it both easier and more appealing for others to jump in and add their own content, I seeded it with all the information I could find or recall.

It is all very well to start a wiki and throw some information in it. But there must be some level of required information to be present, before others with an interest will consider it a viable place to participate. Or before the effort required on their part to add whatever they may have a whim to, is sufficiently reduced perhaps. I spent a day and a half filling this wiki, before announcing it. It will be interesting to see whether anyone jumps on board.

Link: Reverse engineering for the Commodore Amiga

On a related note

The effect of the text rendering shown above, reminds me of the demo DOS by Andromeda. Embedded Youtube video follows..

Let's face it, AmigaDOS in Kickstart v1.3 just looked plain cool with its blue background and white lines.

So I married an axe murderer

In university, one of the films my friends and I enjoyed the most, was So I Married an Axe Murderer. In it, Mike Myers performs poetry, with some kind of band thing going on.



Today, I came across a link to a segment on Conan O'Brien's show, where William Shatner reads from Sarah Palin's book in the same manner. Then Sarah Palin comes out and surprises him, reading from his autobiography. Both read with the musical accompaniment.



Brilliant.

My housing situation

Illustrated using other people's pictures..