And for those who don't know what SWX is (i.e. most of you), it's a new method for Flash applets to talk to servers that entails as little as zero overhead on the Flash side. Basically you send your call over to the server, and a little bit of clever PHP packages up the response as a SWF (i.e. Flash) file. Since SWF files know how to load other SWF files via the intertubes, and since those SWF files you load automatically become part of your SWF's namespace, all that was really necessary was a way to programatically build a SWF file containing only variable declarations, which is what SWX does.
And he also added a lightweight SWX object that makes it look like an RPC mechanism, even though there's almost no code for it on the client side. It makes the server sweat a bit more than sending, for example, an XML file, but I can deal with that. My ISP works on one of those big ridiculous grid configurations like Google, so bringing the server to its knees building tiny SWF files is the least of my worries. Looking at my "how much CPU did you hog this week" graph, I'm not even sure if the grid knows I'm there.
The SWX installation also includes niceties like a services browser and a traffic-watcher, so it's easy to debug.
The other popular solution is Flash Remoting and AMFPHP. Flash Remoting is a fairly simple but not-quite-as-lightweight client-side object. It works just fine but it requires you to buy some server software from Adobe that's not cheap. Enter AMFPHP, which is a knockoff of Adobe's server written in PHP and free.
Only other problem with Remoting is that it's not ported to baby-cellphone-Flash, so if you want your stuff to run on a mobile phone or a Chumby or an iPhone (coming soon), then you need to find an alternative. . .like SWX.
Also interesting about SWX is that it's moving to other server side languages like Ruby as well as other client-side languages like Java. I'm not quite sure of the point in moving SWX to Java as it removes its chief advantage (no overhead) because Java doesn't grok SWF files. I suppose it's for people who aren't necessarily in control of the client development and cannot limit what's talking to their service, so you might as well let other client technologies into the party.
Anyway, I'm entered in the contest as a website and a mobile site. I would've entered the API category, but I'm not sure how popular an open-source API for retrieving daily puzzle high scores would be :)
Wish me luck. You can't stuff the ballot box, so don't try.
