I’m working on an Apollo application that needs to make a TCP connection on a "non-standard" port, which, depending on your environment, usually means a port other than 80, 443, and few other commonly used ports. Development was going fine thanks to the new ActionScript 3 socket object until I went into the San Jose office to work for a day and discovered that the San Jose firewall is much stricter than the San Francisco one, and the port I was trying to connect on was blocked.
Fortunately, most environments with strict firewall rules also provide a way to get around them in the form of an HTTP proxy. After a little research and conferring with Chris Brichford, an Apollo engineer, we decided that this is a common enough problem that it would be worth solving in a generic way. So I wrote the RFC2817Socket class.
RFC 2817 "explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection." Not entirely relevant to our problem, however it also "documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies" which means we can use a common HTTP proxy to make TCP connections on non-standard ports.
The RFC2817Socket class works exactly like the flash.net.Socket class, but if you give it proxy settings by calling
setProxyInfo before calling
connect, it will first handle the negotiation with the proxy server before dispatching the
Event.CONNECT event. (If you don’t set proxy settings, it will work just like the standard socket class.) All you have to know is your proxy server’s hostname and port number, and RFC2817Socket takes care of the rest.
Now that I’m back and building Apollo apps, I’m obviously spending a lot of time with ActionScript 3 again. I’ve been using AS3 since there was a compiler capable of compiling it, but during my sabbatical, I wrote primarily Java and ColdFusion code. Now that I’m back, I have the pleasure of rediscovering all the things I love about ActionScript 3, and all the ways it makes my live easier than it was in the AS2 days:
- Enhanced "for" loops. Being able to use "for..in" and "for each..in" is a huge time saver over the course of several days of programming. Make sure you know when to use which, though.
- The "as" operator. There are two ways to cast objects in ActionScript. The usual syntax of "SomeObject(someValue)" and the new "as" operator. For some reason, I’ve come to prefer using the "as" operator in many circumstances, I think because I often realize that I need to cast something after I’ve typed it, so using "as" lets me do the cast without having to move my cursor back. It’s also slightly more readable, in my opinion. (It’s a small thing, but when you write enough lines of code, small things add up.)
- Regular expressions. All I can say about regular expressions is: how did we ever program in ActionScript without them?
- Sockets. I never felt like ActionScript was blatantly missing a socket object, but now that it’s there, it opens up so many new possibilities (which I’ll be posting about soon).
- e4x. Once you’ve used e4x to manage XML, you’ll never want to use anything else. I got a heavy dose of e4x early on when I wrote the RSS/Atom library, and I got so used to it that dealing with XML in any other language is a huge bummer now. e4x makes using XML as easy as not using it.
Of course, there are a lot of other things about AS3 that I love . I know they’ve been thoroughly covered in the Flash blogosphere, but I’m having so much fun writing Flex 2 / ActionScript 3 code again that I couldn’t help adding one more post. You can check out several examples of these things in action in the Adobe Labs source code repository browser (which I wrote in PHP, by the way, wishing the entire time that I could write it in AS3).
Four months and a lot of lines of code later, I’m back at Adobe. Same company, new job. I’m now working on the Apollo team as an Apollo Application Developer. That means my job is to write Apollo applications as Apollo itself is being developed in order to:
- Give the Apollo team feedback on APIs and other aspects of the runtime.
- Help advise the team on how developers are going to want certain features implemented.
- Exercise the Apollo APIs and look for bugs and usability problems.
- Create a bunch of apps and code libraries that I will give away as sample apps and building blocks for new Apollo projects.
I had a great time while I was off and learned quite a bit about a lot of different technologies which was both refreshing and rejuvenating. When it was time to come back to Adobe, I really wanted to find a job that let me maintain the same level of excitement about what I would be working on day to day. Adobe has a lot of very cool technology in the works right now, but I really think Apollo is especially interesting and has a tremendous amount of potential. I’ll be blogging more about Apollo as I learn more myself.