Fifty-four forty or fight!

Today I flunked this quiz question asked of registrants for a Dell sweepstakes:

Where in the U.S. did Dell recently build a Customer Contact Center?

• Roseburg, Oregon
• Oklahoma City, Oklahoma
• Edmonton, Alberta
• All of these

Yep -- I missed the correct answer: "All of these." (When did we get Alberta?)

And I had never heard of Doug Engelbart!

Since Reginald B. and Alan Kay have urged us to google Doug Engelbart, I reckoned it must be important, so I did. And I found this amazing demo from 1968 of, basically, my computer.

RIA Not Advancing the Ball

Rich widgets obscure the semantics of hypertext. Only the code behind the form knows what the widget really does. Contrast to HTML 5, and in particular Web Forms 2. These guys are extending HTML to capture what we really do on the web. As a consequence, client programs can (or, have a chance to) understand the meanings of hypertext documents from the web.

Example: you want to write a script to automate some remote bookmark service, as part of your mashup. But this service, unlike del.icio.us, has no documented "API". So you have to download its form, complete it programmatically, and POST an entity.

Case 1: The form uses Plain Old HTML. You're golden. All the semantics are right there for you to parse, or read. You identify the name of the text box where you stick the URL, and the name of the text box where you add a description. You compose the URL encoded form data, and POST it to the action URI.

Case 2: The "form" uses Javascript to modify the DOM on the fly: the onload() method adds text boxes, and a submit button, to an empty DOM. In fact, it might not even use the submit button as a form element; when you press the button, its onclick() might send a custom XMLHttpRequest back to the server. Your code will never automate this interaction.

Case 3: The "form" uses XAML + Silverlight plugin. An exacerbated case of (2).

In contrast, Web Forms 2 attempts to capture the semantics of what we do with forms. Because browsers will understand more of the semantics of the form, we can do declaratively what we now have to do in Javascript. For example, lots of HTML forms now have to use script to add a row of controls to a form on the fly ("Click here to add another bookmark"). WF2 captures that as repeating control groups, and the browser can handle it.

(Then again, I am a documented forms nut.)

Mike Dierken justly analogizes: "RIA is to user interfaces as RPC is to messaging interfaces". And notice, it's Rich Internet, not Rich Web Applications. These technologies pay lip service to the web, but they're not advancing the ball toward building more and better links throughout the web information space.

P.S. Wonderful rant by Mark Pilgrim!

Update: fixed a link.

RIA -- Fill 'er Up!

I'm having an ongoing email exchange with my friend Peter. He's convinced MS and Adobe herald a new age of Rich Internet Applications. He pointed me to this guy who's backed up a tanker to the Kool-Aid trough.

Sure, MS and Adobe have to sell something as the Next Thing -- what else have they got? But we've had RIA ever since Java 1.1 applets. We have Flash. We have <embed> and <object>. Do you really think what's been holding RIA back is the technology?

Users have voted with their mice, and they've voted for the web experience -- exploring the web information space using hyperlinks -- as far more important than whizzy UI. Ask eBay. Ask MySpace.

Flash, applets, Silverlight, Javascript -- the more you use them, the suckier your web apps are at exploring the web information space. I don't think it has to be this way, but it takes a design discipline few seem to have. These programming models are from the 80s. They have web APIs, but they're not web oriented. Programs end up as little desktop applications, not web apps. I don't see Silverlight changing that. It is good to have super expressive widgets -- hear hear. But if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space.

The Penny Drops

It's enjoyable, and instructive, to watch the penny drop for venerable DCOMster/SOAPster Tim Ewald: I finally get REST. Wow.

Instructive, because coming from a strong RPC perspective, Tim illuminates the distributed application problem with slightly different shades. I like this graphical model:

Every communication protocol has a state machine. For some protocols they are very simple, for others they are more complex. When you implement a protocol via RPC, you build methods that modify the state of the communication. That state is maintained as a black box at the endpoint. Because the protocol state is hidden, it is easy to get things wrong. For instance, you might call Process before calling Init....The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you're moving to, making that your new state. A state's representation includes the links (arcs in the graph) to the other states that you can move to from the current state.

Austin to Paris in 30 days

Since I'm traveling to Paris soon, thought I'd get directions from Google Maps. It's going to take 30 days, 9 hours. Notice item 28. (via Peter Flanagan).

Twenty miles with the Tour de France Champ

Today I rode 20 miles with 2006 Tour de France Champion Floyd Landis. And I don't care who knows it.

Microsoft is Dead

Ha! I've been telling people Microsoft has become irrelevant. And now Paul Graham crystallizes the thought. Especially rich:

...I'm now surprised when I come across a computer running Windows. Nearly all the people we fund at Y Combinator use Apple laptops. It was the same in the audience at startup school. All the computer people use Macs or Linux now. Windows is for grandmas, like Macs used to be in the 90s. So not only does the desktop no longer matter, no one who cares about computers uses Microsoft's anyway.

An irascible colleague at a large software company used to say, "Hugh, you have to understand: XYZ isn't really a software company. It's an old folks home for software." XYZ had the same problem PG describes:

Microsoft's biggest weakness is that they still don't realize how much they suck. They still think they can write software in house. Maybe they can, by the standards of the desktop world. But that world ended a few years ago.

The cure is worse than the disease

This paper from Fortify makes the case that sending sensitive information using JSON exposes it to cross-site maliciousness. GMail sent your contact list down as JSON and evaled it. Turns out, any old site could do the same: just put a <script> tag referencing that contact list, and install some interceptor code that overloads setting e.g. the "email" property on any object: That enables the malicious code to see the values in the JSON.

Here are a couple of their proposed measures:

1. "Add the session cookie to the request as a parameter." Knee-slapper, that. See, the exploit only works because vulnerable sites put your identity into the cookie, and use a single URL for all users to download the object; the server uses the cookie to send you your personalized contact list. So the attacker just has to hardcode <script src="http://yoursite.com/contact-list">. The paper proposes uniquifying the URL. Here's an idea: design your app so that each user's info is at a unique URL in the first place!

2. Send all legitimate requests for JSON data using HTTP POST! That way you know any GET requests are malicious ones from <script> tags. They do concede that "The use of GET for better performance is encouraged by Web application experts from Sun and elsewhere". There's no use for this measure if you use unique URLS, of course.

So yeah, this is a serious problem, but not for apps using best web architecture practices. Millions of web developers read papers like that and then crap all over the web.

Life imitates art

During the Atom Publishing Protocol process, posting your cat pictures was a recurring use case. Now there's a whole site devoted to social cat picture publishing. John Panzer, is that you?

Update: I guess it's not John -- they only expose an RSS 2.0 feed.