New Toy

I have a new toy on back-order with Amazon.

In short, I'm after most of the iPhone features without the phone part. I want:

• A Video Player (including DIVX)


• A Music Player (including OGG)


• A browser over WiFi in a pinch


• A small form factor with decent battery life


• WiFi connectivity

It's not an ideal device, but it's a start.

• I'd like to see an iPhone-like browser, but Opera will do - this isn't my main browser
  
• If I need a full-power browser I'll bust out a laptop.


• I wish I had a competitive device that would play iTunes content

As an additional plus, the Archos will allow me to play Flash content. In general, I'm not seeing a compelling reason to purchase an iPhone over the 605. At a minimum, until until Apple fixes the iPhone's Bluetooth stack to let me sync calendar and contact over Bluetooth, I'll be looking elsewhere.

Enough with the Thai Already

I love living in Portland for many,many, many reasons. But enough already with the lack of food diversity. A local sketchy Teriyaki place just closed down in my Hollywood neighborhood. What opens in it's place? Another Thai restaurant. I won't be going there, I already have a Thai rotation of some really good places, I don't need another. I can count at least ten in a three mile radius, Google says there are more. So, if you're opening a new restaurant in Stumptown, I submit:

• No more Thai


• No more Pho


• A strong Indian effort would make a killing

OMG What Happened to My H3@d3r?

Wow, read this from Scott Chapman which got me down. Yet another attempt to do REST from a Flex app with significant hackery bolted on, fails. I've said it before, when you are concerned with your HTTP headers, you are fighting the wrong problem. I don't spend much time thinking about my TCP window scaling, why should I have to constantly focus on HTTP protocol-level craps?

I'll say it again, someone needs to step-up and write an ActionScript HTTP client. Until that happens, the browser and it's FVM cohorts are the wrong platform for RESTful requests.

Toss the Bath Water and the Baby

Bill Bill de hÓra picks up on the broken-ness of the Flash VM's ability or lack thereof to expose headers to the fault callback. He also pulls in to hell with bad web clients. As I read that, I'm convinced that Flex is actually my escape hatch from browser insanity. I'm heads down in CSS Mastery at the moment trying to make my nav bar behave sanely across browsers for some non-profit work I'm doing. It's sick the amount of work I'm doing to make sure A is left of B in IE 5.5 on Mac *and* IE 7 on XP x64. Comparatively, the time spent doing the same thing in Flex would have been 1/10th the effort if that. So, I actually agree with Bill on this, we should get rid of bad clients, those bad citizens of the web that break and hurt our beloved web.

That's right, we need to toss out the browser all together. Em, or even better, let's actually make our browsers behave as good citizens in the HTTP multiverse that is bearing-down on us like a freight-train made of UTF-8 printable characters (and none of those binary, non-readable ones either thank you very much). As an open message to FF, IE, OP, KQ, etc., I want DELETE. I want access to headers in my XHRs, I want full control. You want to hide it from me, the ignoramus developer because I'm not ready? Ok, wget, here I come!

XMPP MIA?

I've been trying to hit-up xmpp.org for two days now and nothing, nada, zilch from their authoritative DNS server. My dig for the www looks like so:

--> dig www.xmpp.org

; <<>> DiG 9.4.1-P1 <<>> www.xmpp.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54001
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.xmpp.org.                  IN      A

;; AUTHORITY SECTION:
org.                    45762   IN      NS      TLD2.ULTRADNS.NET.
org.                    45762   IN      NS      TLD5.ULTRADNS.INFO.
org.                    45762   IN      NS      TLD4.ULTRADNS.org.
org.                    45762   IN      NS      TLD6.ULTRADNS.CO.UK.
org.                    45762   IN      NS      TLD3.ULTRADNS.org.
org.                    45762   IN      NS      TLD1.ULTRADNS.NET.

;; ADDITIONAL SECTION:
TLD2.ULTRADNS.NET.      45863   IN      A       204.74.113.1
TLD5.ULTRADNS.INFO.     1251    IN      A       192.100.59.11
TLD4.ULTRADNS.org.      45762   IN      AAAA    2001:502:100e::1
TLD4.ULTRADNS.org.      45902   IN      A       199.7.67.1
TLD6.ULTRADNS.CO.UK.    477     IN      A       198.133.199.11
TLD3.ULTRADNS.org.      45863   IN      A       199.7.66.1
TLD1.ULTRADNS.NET.      45762   IN      AAAA    2001:502:d399::1
TLD1.ULTRADNS.NET.      45863   IN      A       204.74.112.1

;; Query time: 62 msec
;; SERVER: 209.244.0.1#53(209.244.0.1)
;; WHEN: Wed Aug 22 23:49:06 2007
;; MSG SIZE  rcvd: 344

I like XMPP, I do. But if *they* can't get their DNS right, I'm scared (XMPP depends heavily on DNS working properly).

Easy Peesy

Making it stick.: The "Ease" Argument Again?

I've got Patrick's back on this one, I have a hard time believing that anything that starts with WSDL is going to make my life easier.

I like Dan's project, I do. I think XFire is the way to go if you have a hard and fast requirement to expose a Java-based service via SOAP. But make sure you actually need to go there before you do. If your biggest customer says "we use SOAP and only SOAP" for integration with trading partners, hello XFire.

Thus lies the path to Kakotopia! In my experience, you won't be pointing any tools at each other that actually grok that WSDL and can talk to each other without serious intervention on your part. My last experience trying to do this very thing was a Java/.NET integration for a project was about two years ago, the experience went something like this:

1) Expose XFire service by configuring Spring adapter booya
2) Check WSDL - looks OK, not that I'd know without studying the spec
3) Use VisualStudio .NET Stub generator wizard to create a C# class for invoking the service.
4) Try and run the class from step 3
5) Witness failure, something about unsupported binding
6) Read this.
7) Change API to XML-RPC.

I have about eight of these stories, some of them end with me snooping HTTP Headers because of obscure server errors. Some, like a recent attempt to create a Flex service to consume Confluence's WSDL end with obtuse client-side schema errors. That's about all the CPU cycles I give to these types of things, after that I fall back to things I can control and see. Maybe some day it will work, but I haven't seen it materialize yet.

Given recent episodes with REST, I'm not sure it's a clear winner from the browser either, because I again find myself looking at HTTP Headers to try and figure out what is broken. I don't want to spend my time doing that. Seriously, I'm done breaking out Wireshark to troubleshoot protocols that work until people try and get cute with them.

RESTful Flex Angst

Following on the previous post about issues encountered getting Rails and Flex to play together, we've now observed that certain popular browsers do not correctly interpret the HTTP specification for status codes on HTTP responses. Namely, IE 6 (haven't tested 7) treats any 200 status code other than 200 as an error. Perform an overloaded POST to a RESTful service in IE and get a 201 back, IE exposes a status of error to interested applications.

Why does this matter? When trying to do Flex integration with a Rails back-end, we are required to rely on Flex's callback mechanism to tell us if we get a result or a fault. Flex apparently, relies on the browser's plumbing to determine the success of the request. So, updating a RESTful resource via a Flex HTTPService for example appears as a failure at the Flex layer because IE tells the FVM that it got an error. This was the source of great angst for us because most of us test our Flex applications in Firefox.

The problem is further compounded by the fact that Flex doesn't expose any of the raw response data to us, simply a FaultEvent with little useful information (one of the dreaded stream errors actually). No headers, no body content, nothing. I've seen blog posts that hint at this being a limitation of the FVM's status as a lowest common denominator runtime, Flex included - some browsers don't expose headers to plug-ins so neither can the FVM.

When I find some time, I'm going to fire up the ActionScript Socket API and write an HTTP client that doesn't require overloaded POST, that exposes plumbing of the HTTP, and that allows *me* to determine what is or is not an error.

Alternatively, I've got a more simple tool in the works that will allow you to test HTTP methods of all sorts and status codes propagate back into the FVM.

In a future post I'll dig into some of the interesting behaviors we found examining these behaviors from the stand-alone player and how it does it's networking.

RESTful Rails Angst

I've been working with Rails to provide RESTful services to a Flex application recently and a number of issues have come up that people need to know about dern it.

Today's story entails a battle with Rails' scaffold_resource. The RESTful generator makes a noble effort to create RESTful controllers. However, a few minor issues pop-up that need repairing in the current incarnation of the generator.

The most glaring issue is that the default code doesn't handle ActiveRecord find errors gracefully. For example, if I have a FoosController servicing requests to "/foos/1.xml" and that model :id=1 doesn't exist, the default FoosController will throw a RecordNotFound which up the call stack results in a 500 error being returned to the client. This, is unfortunately not "RESTful" as they say. The correct behavior would be to return a 404 indicating that the desired resource does not exist, not that the server could not handle the request. Adding this behavior is not difficult, but it's somewhat tedious in that each generated controller exposes four find calls that can fail in this way.

Additionally, as Peter Armstrong's solid PDF-only book on Flexible Rails points out, the default implementation of to_xml used throughout the controller is quite painful for certain clients. Most programming languages don't allow "-" in member names and as such, mapping tools that attempt to make XML traversal easier by exposing the XML structure as a choke on the default XML marshaling. As Peter points out, you can change this behavior by adding the ":dasherize" option but again, this is all over RESTful Rails controllers.

I could fix both of these through some hacking on the Rails distro, but then I have to remember to keep my changes across upgrades. Another option would likely entail injecting some app-specific base classes into the hierarchy, again not an idea I'm crazy about. If I come up with a better approach, I'll post it here. Or maybe back as a patch :)