BitWorking

Color me shocked, but IBM has just rolled out a cloud computing offering. For the short year that I worked at IBM I argued many times for IBM to enter SaaS, but to no avail, so it's great to see them finally entering the field. Now this is IBM and those bureaucratic genes run deep, so don't expect to just whip out a credit card and start playing:

• Fill out a test drive enrollment form
• You will be contacted by an IBM CoD specialist to discuss the offer and agree to terms including a small activation fee of $99 and desired start date
• You will be issued instructions, a VPN ID and password to access an isolated cluster in the IBM CoD center for the agreed upon timeframe
• You can try the service up to 3 days

I can only imagine the process if you want to actually sign up and do something. Regardless, I take it as a positive sign that IBM has finally arrived.

An upfront disclaimer, I work for Google. I am not involved in Wave in any way and all of the things I discuss below are based on external documentation.

Before getting into the specifics of the issues I found, I want to point out that I'm very excited by Wave, I believe it has tremendous potential. The team has also done a good job re-using existing technologies, and providing different protocols and APIs for the various ways you can interact with a wave server.

There are actually 3 protocols and 2 APIs that are used in Wave:

• Federation (XMPP)
• The robot protocol (JSONRPC)
• The gadget API (OpenSocial)
• The wave embed API (Javascript)
• The client-server protocol (As defined by GWT)

The last one in that list is really nothing that needs to be, or will probably ever be documented, it is generated by GWT and when you build your own Wave client you will need to define how it talks to your Wave server. The rest of the protocols and APIs are based on existing technologies.

The robot protocol looks very easy to use, here is the code for an admittedly simple robot. Now some people have commented that Wave reminds them of Lotus Notes, and I'm sure with a little thought you could extend that to Exchange and Groove. The difference is that the extension model with Wave is events over HTTP, which makes it language agnostic, a feature you get when you define things in terms of protocols. That is, as long as you can stand up an HTTP server and parse JSON, you can create robots for Wave, which is a huge leap forward compared to the extension models for Notes, Exchange and Groove, which are all "object" based extension models. In the "object" based extension model the application exposes "objects" that are bound to locally that you manipulate to control the application, which means that your language choices are limited to those that have bindings into that object model.

All of this is very new, Wave is just starting a developer preview, and the documentation of the protocols and APIs is thin or non-existent in areas. In my observations below I've concentrated on the areas that do have documentation.

Well known location

The robot protocol uses a "well known location" for the Robot Capabilities files. I've just about given up on arguing against protocols that introduce new "well-known locations" in URI space. The problem is that all the other alternatives are problematic either on the server or the client side. If you are going to introduce a new location, at least follow the lead of the WebFinger Protocol and put it below the /,wellknown/ path.

Hypertext

If you are going to introduce a "well-known location" then make good use of it and boot-strap the rest of the URIs for the protocol from there. In the case of Wave, put the URI of the robot jsonrpc URI in the capabilities.xml, don't make it its own "well-known location". Ditto for the profiles URI.

XML and JSON

There's a mix of formats here, XML for the configuration and profiles, but the actual protocol is JSON. Why not simplify and make it JSON all the way down?

NG and Schema

In the same vein, the federation protocol schema is specified in RelaxNG while the extension manifest is defined via XML Schema.

The above points are relatively minor and I'm sure I'll have more feedback as more documentation rolls out, but I'm very excited by the technology and the direction the team is taking with Wave.

We got a gift in the mail of some Kansas City Steaks. The kids' reaction was "We got dry ice!"

It's been a while since the URI Template draft has been updated, and in the interim there has been some implementation experience:

• http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
• http://code.google.com/p/uri-templates/wiki/Implementations

In the intervening months two things have happened:

1. In all the URI Template examples I've seen, only the simplest case {foo} has even been shown.
2. I've been repeatedly asked about "going the other way", i.e. parsing URIs based on templates.

This leads to two questions:

1. Are there any real-world uses of the more complex URI Templates, or is {foo} enough?
2. If the syntax is simplified to {foo} there is an opportunity to support the parsing case, ala WSGIDispatcher Is that of interest to anyone?

Feedback on the W3C URI mailing is appreciated.

The video for my design patterns talk at PyCon 2009 has been posted:

The impetus for this post in part comes from a conversation I had at PyCon. A developer had admitted that in the past he had served up a high-traffic web page that was the same for every visitor, but then used a bit of Javascript to pull up the users information separately to customize the page, but he felt "dirty" doing it. That was pretty surprising to me because it's a perfect use of Javascript, and it highlights a misunderstanding about the role of Javascript in the web.

Sean McGrath:

I don't know which way it will go but I would suggest that if we are searching for what exactly the web *is* we have to go further than say it is HTML, as Hugh does in this piece.

For me, the web is URIs, a standard set of verbs and a standardized EVAL function. The verbs are mostly GET and POST and the standardized EVAL function is the concept of a browser that can EVAL HTML and can eval JavaScript. I don't thing we can afford to leave JavaScript out of the top level definition of what the Web is because there is too much at stake.

The short answer is that using Javascript can be RESTful:

Fielding Dissertation - Section 5.1.7:

The final addition to our constraint set for REST comes from the code-on-demand style of Section 3.5.3 (Figure 5-8). REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional constraint within REST.

The emphasis is my own, and is the crux of the problem, that using too much Javascript can reduce visibility, not only to intermediaries, but also to other denizens of the web, like crawlers.

There is a broad range on which Javascript can be applied in building a web site, from sites that use HTML and CSS only, to sites that require Javascript to access any functionality. The latter are what I call "empty window" interfaces, because if you visit the site with Javascript turned off all you're going to see is an "empty window".

GWT and Search Engine indexing:

You're barking up the wrong tree here. GWT is for writing AJAX/RIA/whatever-you-want-to-call-them applications. It makes the obnoxious JS bits tolerable. JS applications are inherently unfriendly to search engines. You can overcome that (as Ian has done) but it isn't going to be as simple as tossing an HTML file on some random web server and having it indexed.

It's picking the right range for your application to sit in that matters, and picking that range depends on how searchable you want to be.

Simon Willison:

Annoyed at Google Moderator http://moderator.appspot.com/ - I can see absolutely no reason why it should be a JavaScript-required service

NIST is assembling standards around SaaS, and one component of that standard is understanding the value of the data versus the risk of it being exposed. We need a similar decision framework for web applications, but in this case the reverse, the value of the data versus the risk of it not being indexed.