chrishowie.com

I’ve abandoned my idea of creating an AJAX interface for the time being. It is a cool idea but I think I can do much better by writing a proper application.

The Linux FICS interface scene is rather weak. eboard is about the best there is in terms of usability, and it has its share of problems. xboard is there for the minimalists who want their interface to provide a chess board only. When compared with the powerful and extensible interfaces available for Windows it’s rather a shame there’s nothing similar for Linux.

So I’ve decided to take the name I was going to use for my web interface and apply it to a new Linux interface. Building on Mono.Addins, I’ve already got an interface that can be extended in several key ways. Addins can, for example, provide new text highlighting classes or classes that can manipulate the console text buffer in interesting ways.

Using a tip from jonp in #mono, I have now come up with an extensible preferences system that does not suck, based on XLinq. Addins can simply subclass PreferenceContainer, slap on a few attributes, and they have an easy-to-use set of strongly typed preferences that get automatically serialized to XML. Right now only the basic primitive types and strings are supported, but this will be extended later to include things like arrays, lists, and XLinq objects. Thanks to Mono.Addins and some more support classes I wrote, addins can also provide Gtk# widgets that get embedded into the application preferences window. By writing very little code, addin authors can persist their settings and provide the user with a convenient way to change them.

I’m still lacking a chess board though. If anyone likes writing custom widgets and feels comfortable working on this project let me know. The sources will be made public in the coming weeks after I’ve had a chance to polish them and set consistent style guidelines.

I’ve been getting back into chess recently, and my favorite online community is the Free Internet Chess Server (FICS). There are a wealth of free and open interfaces available for download, but they all have one thing in common: you have to download them. At my workplace this is a no-no, but over my lunch break it would be nice to get in a few games. If I forget my laptop then I have no way to play.

Enter Gazebo. I started this project last Friday night, so it’s only been about two days. Still, what I have right now is rather impressive for that amount of time. At face value, the current version is not very representative of the time that’s gone into the project so far, and for a very good reason.

The HTTP protocol used by web servers was not engineered around the idea that you’d establish a long-lasting connection with the server. It’s better suited for quick request-response cycles. Because of this, the PHP web service has no good way to maintain a connection to FICS.

The solution I came up with for this problem is simple, yet very involved. A daemon script (yes, written in PHP…) listens on a UNIX socket for connections from the PHP web service script. If a new FICS session is requested, it creates a new session and returns some authentication parameters to the web service. On every request to the service, another connection to the daemon is made over the UNIX socket, the session attached to with the authentication parameters, and some action taken, like “write this to the network socket” or “tell me when you get new data from the network socket” or even “close the network socket and destroy the session.” The daemon essentially acts as a super-proxy that persists the network sockets and enables access to all of them from one UNIX socket.

Yes, it’s kinda ugly. But it also works incredibly well. There is still some tuning to be done, but behold the awesomeness of what is essentially in-browser, color-coded telnet: