Python: Class objects as signal arguments

Today I was writing python wrappers for the Windows device installation and management APIs (setupapi.dll) and ran across the SetupDiSetClassInstallParams(W) function in which I needed to not only accept a hardware profile identifier, but also accept special signal values indicating "all profiles" or "current profile". The underlying Windows API does this using a flag to specify that all profiles are to be affected, and the profile ID #0 to mean the "current profile" should be affected. However, since I'm presenting a pythonic interface with my wrappers, this was unacceptable -- I wanted named values that could be passed as the hardware profile identifier argument that would represent these two special cases.

In other words, I just needed a way to identify whether the argument passed to my wrapper was one of two reserved values I was using to signal special behavior as opposed to the actual hardware profile ID. In addition, it would be great if I could attach python doc-strings to the signal values to document what they mean and what they are used for.

I'm sure my solution is less clever than most, but I used classes as the signal values. Since classes are objects in python, I don't need to actually instantiate them -- I just use the class objects themselves as the signals. As an example:

class AllWidgets(object):
    """Placeholder for indicating action applies for all widgets
    """

class CurrentWidget(object):
    """Placeholder for indicating action is applied for just
       the currently selected widget
    """

def ApplyFlavor(flavor, widget=CurrentWidget):
    if widget is CurrentWidget:
        # Code that flavors the "current widget".
        ....
    elif widget is AllWidgets:
        # Code that flavors all widgets.
        ....
    else:
        # Code that flavors just the widget specified.
        ....

SCTP as a game transport protocol

Last fall, Dr. Ilmi Yoon kindly let me present some research I had done regarding the SCTP protocol to her CSc 631 Multiplayer Game Development class at SFSU. The slides (ppt) and handout (doc) from that presentation are online.

To keep the talk topical, the presentation first covered the pros and cons of both UDP and TCP in the context of online games, specifically MMORPGs. Then I explained the features of SCTP and how those features related to those of UDP and TCP. Finally, I presented research showing how SCTP's performance characteristics were favorable to traffic similar to that of current MMORPGs. Most of the numbers presented come from third-party research papers, so the fact that I have never worked in the game industry shouldn't detract from the relevancy.

In case anyone finds them useful, I also have my research notes (doc) for the presentation online. These consist of short summaries of most of the RFCs and academic papers I consulted in my research. I won't vouch for their quality, though, as they were never intended for public consumption. I just used them to make sure I properly cited my sources.

Update 2007/03/28: I put HTML versions of the PowerPoint slides online.

No A, no X, just JA

I was just looking through some of the old code on my web site and ran across this blast from the past: an online othello game I wrote all the way back in the year 2000.

A couple of years prior, I had been teaching high school students how to program in C/C++. Othello seems to be just about the right level of complexity for beginning programming students.
One Saturday in 2000, I gave myself the assignment of implementing all the logic I had expected from the students myself, only I made myself do it in JavaScript as a refresher.

Libraries, not frameworks

I'm not a web programmer by trade, but I've been known to dabble in it from time to time. Now is one of those times. I've used perl, php, and even C to develop web applications in the past, but my current language of choice is python.

Now, python comes with some excellent low-level libraries for web programming. The cgi and Cookie modules take care of most of the work of parsing HTTP requests and python's WSGI standard adds a slightly-higher level abstraction to the time-honored CGI protocol. Python 2.5's wsgiref module provides utilities to aid developing WSGI-compliant applications and even includes a sample server that makes it trivial to test your web applications.

Unfortunately, the bundled libraries only handle the low-level request handling. For example, localization is important to me, so being able to easily access the Accept-Language HTTP request header is nice, but it would have been even nicer if there had been a library function to parse its contents. Now consider that there are some 28 different request headers defined in HTTP/1.1 and we see that some higher-level libraries would make life easier.

But where are these libraries? They are embedded inside byzantine web frameworks and every framework implements their own. I don't really care to pull in an entire web framework when all I want are the high-level request parsing tools. And code re-use through cut-and-paste just perpetuates the problem. Paste appears to be the closest thing to a library going, but still manages to miss the mark by being a collection of libraries that do various things, not all related.

What I'm looking for is a library: not a framework, a library. I'll make one if I have to -- a small library that does one thing and does it well. Call me crazy, but it doesn't look like I'm the only one who thinks small, sharp tools are the way to do web apps.

Late to the party

My name is Kelly and I'm an idiot. There, I said it.

For years the blogging phenomenon has reminded me of the quote, often attributed to Mark Twain, "Better to keep your mouth closed and be thought a fool than to open it and remove all doubt". Hence I've been following my friend JJ's blog with a bit of curious scepticism. However, the excellent feedback and generally friendly attitude of most of the commenters on his blog has given me the courage to give it a try myself.

I don't really know what I'm going to blog about yet. I do software engineering of all sorts, both professionally and personally, and I've been studying Japanese for almost 6 years. Both of which pretty much consume all of my time. I stopped watching TV about 6 years except as Japanese study practice (channel 26 here in the Bay Area offers a variety of Japanese programming Saturday and Sunday evenings). I haven't listened to radio in almost as long. Which is to say, I'm generally pretty boring.

Oh yeah, and I'm a fool. But you'll see that for yourself.