Responses to the announcement of the Google App Engine have been mixed, from Tim Bray’s somewhat negative Sharecropping, to an awful lot of “very cool“s, with Niall Kennedy’s tech description providing a reasonably neutral common ground. I’ve been meaning to post about it, but I’ve a couple of pressing deadlines and haven’t had time. I didn’t think “Python - great! But this thing really isn’t forward-looking” would be doing it justice. However this morning I ran across a couple of blog posts on which I felt obliged to comment, and I just realised that most of my main points about the Google App Engine leaked out into those comments. So with apologies in lieu of better treatment, here goes -

Comment on Gabe Wachob’s Google App Engine: Its the Architecture Stupid! :

Nice post! The first I’ve seen to highlight the significance of the architecture.

While I think your analysis is generally on the nail, I’m not so sure about the conclusions. The thing is, App Engine architecture isn’t Web architecture.

As you point out there are nice reusable abstractions (like events etc), but the primary interfaces are all down at the code level.

“If you build your app on the Google App Engine architecture, it will scale to unlimited levels without any extra effort.” - yes, but only on the Google App Engine.

Rather than hoping for open source implementations of similar toolkits, if a HTTP facade were put over things like BigTable, the specific implementation wouldn’t matter - to change that you’d only have to change a few URIs, not all your code. (One for the LazyWeb).

Commoditization (commodification?) works best where there are common standards. A railroad engine isn’t a commodity if you have to build your own track

See also: Cloud: commodity or proprietary?

Comment on Swaroop C H’s Web dev frameworks vs RIA :

[On the question of how one develops both client- and server-side with frameworks] I’d suggest that if Web standards are used as a common interface, it really doesn’t matter!

Ok, an example. A while ago I needed an easy personal activity tracker. I wanted it in my face a bit on the desktop, which called for something RIA-ish. I wanted the data available in a form that’s reusable, and I want a straightforward view on the web (so my colleagues could see what I was working on).

So I wrote a little desktop app in Java. It’s essentially MVC, with a fairly trivial domain-specific model - I have activity items with title, description and tags.

Server-side I have a Talis Platform store. The desktop app communicates with the server by POSTing a chunk of the domain-specific information expressed as an RDF/XML doc - the stores have this kind of interface out of the box.

For my simple Web view of the data, I have a little bit of PHP which does a SPARQL query on the store (standard SPARQL-over-HTTP endpoint also comes out of the box) and uses XSLT to transform it into the JSON consumed by SIMILE’s Timeline viewer.

Unfortunately I broke the Timeline viewer bit of the app (I think I got out of sync with SIMILE’s scripts). But hopefully you get the idea - small domain-specific components, loosely-coupled using a standard general-purpose protocol (HTTP) and standards general-purpose data model (RDF).
For reuse, I can query the store however I like.
[I got distracted and forgot to link to implementation note: More Dogfood]

Ok, I’m showing my bias towards a data-oriented shared model in these comments. But if you wanted to narrow things down a little and be more content-oriented (and maybe placate Mr. Bray a litte), swap out the RDFisms and replace them with Atom/AtomPub. The key point is providing a common interface based on standard models, message formats and protocols. (Interop between Atom, RDF and any other systems which respect WebArch is generally doable because of that common interface).

One other point I’d like to add which I suspect speaks volumes about Google’s mentality is the difference between a real aeroplane and Google App Engine’s snazzy logo. Compare and contrast with the image above:

Share This