Dilemmas

The following case study came unbidden, and thoroughly disrupted my carefully arranged plans. I tend to accept these twists of fate these days. Thus I give you a diversion that I nominate as Part 10 of the Things Fall Apart series, another entry that falls under the banner of Social Living. Do let me know if it fits the bill.

An Examination Question

Date: Saturday June 10, 2006
Time: 8:55 am EST

Problem Statement

You are manager of Toli inc., a small but growing concern. The following situation presents itself to you. Discuss how you would resolve the various competing concerns. Provide enough detail to satisfy the reporting requirements of the Sarbanes-Oxley act in light of the corporate history of Enron and recent judicial verdicts.

Constraints

Hunger: You haven't had any breakfast although you woke up at 6 am on the dot as is your custom this time of the year. The reason for the delayed breakfast. Well...

Dying computer: Your desktop computer has been giving you fits for the past 3 hours as the power supply cuts out every five minutes as a result of being subjected to one too many lights out. More disaster recovery in prospect.

Laundry: There are at least 3 loads of laundry that need to be washed if you want to have something to wear this evening beyond tracksuits.

World Cup: the England vrs Paraguay match starts at 9am. 5 minutes.

French Open: the women's final starts at 9am. Or has it started already? Henin-Hardenne against Kuznetsova.

Day job: Need to check in the code that you promised the team this week. You want to be the Karl Malone of Lotus: "The Mail Man, I deliver". Prospects are dim.

Marriage: Desire for quality time with The Wife. 'Nuff said.

Groceries: Probably a good idea to do. See also: marriage.

Family: The mother-in-law is in town. You should see her sometime today. Also: need to do weekly phone calls to Ghana and all the cousins and friends. You remember that 8 members of the family are due to head to Germany today to support the Ghana team. You need to find out whether they got visas. Basically, catch up with people, talk football.

House: A mess. See also: mother-in-law.

Reading: you normally curl up with a book or three on weekends.

Futures: The Great Move West beckons, you have a month or so to finalize on the moving company, pack your apartment, and purge your possessions. Would be good to get a head start. See also: house and marriage.

Bills: The usual suspects need to addressed. Corollary: day job.

Preliminary Solution

Prioritize: football, laundry, house, mother-in-law, bills, reading, The Wife, day job, hunger (you'll work the rest out later).

Risks: marriage (justification: "in good times and bad"), day job (justification: well it is Saturday), tennis (life is like a box of chocolates), groceries (whatever), The Move (next week).

You're an engineer but technology can only help so much... You could use a Tivo, but even if you had the prescience to have bought one, it would only be good for pausing if you have to run out for a minute. With an event like the World Cup, you can hear the screams of people in nearby houses and in your building. Your upstairs neighbour, like you, is living every moment of the matches and your ceiling felt every half chance yesterday. Unlike that guy at the office who got his Tivo installed on Monday, you have procrastinated. You don't even have VHS tapes to record the games on your old vcr. Also your old TV doesn't have split screens. In any case, you don't like switching during football matches. Well maybe rolandgarros.com, there's an idea: laptop deals with tennis and day job in one stroke...

The immigrant workers outside your window have a radio blaring as they work, so they too are in the mix.

The Set-Up

1. The TV situation

Yesterday you started looking into the furniture business and adjusted the TV stand so that the angle is more amenable for long term viewing. Final is July 9th.

Within reach are two of The Wife's travel neck pillow things. They might come in handy since you are using your 10 year old bachelor futon: furniture from hell and source of chronic back pain and worse. Resolve: Burn it during The Move.

You have six pillows to fashion the futon into some semblance of comfort.

Remote control for switching back and forth with tennis. Check.

Sleep cloth, Dutch wax. Check. Good Ghana boy.

New cell phone. Check. No longer a high-tech Luddite.

Cordless phone for landline. Oops. Need to recharge it. Head to study.

Broom. Within sight.

2. The Laptop Configuration

You don't like to use laptop keyboards for extended periods, you normally use a full-sized keyboard and monitor on your desk in the study. This situation however calls for a laptop intervention.

You borrow The Wife's Cool Pad to prevent the scorching of the family jewels. The wireless access is all set... You decide you need to order one of your own pads. You open up a tab in the browser, search for "Cool Pad" at Amazon... open up another tab for Froogle "laptop accessories pad", another one for PriceScan

You get up to grab the laptop power cord from your study, you don't want to run on battery today.

3. Reading Material

1 copy of Friday's New York Times. You only buy the hard copy on Fridays and Sundays and don't have home delivery, it forces you to go to the convenience store to commiserate with that Persian guy about Dubya bombing his hometown two weeks before the upcoming November elections. Jesus wept. You bought said copy during the hour between games yesterday but have only read the front page... Remaining: the arts section, Krugman and that whole Zarqawi thing...

Kwasi Wiredu - Cultural Universals and Particulars, An African Perspective. Some philosophical reading for the theme for your Social Living series.

Madison Smartt Bell - The Stone that the Builder Refused. You've been carrying this novel around for two weeks and it's getting great. Haiti. Toussaint L'Ouverture. Napoleon. Revolution! Things fall apart.

All set for World Cup.

9:02am. Laundry. Quarters. Quick: downstairs. 5 minutes to go.

The Match

9:06am. Couch. Remote. TV. Okay.

American TV channels don't show the build up of the games unless the US is playing, the broadcasts start on the hour so you only get 7 minutes of pre-game commentary. There's barely enough time for analysis and you don't get to hear the national anthems unless the US is playing... And then there's the fact that if it's on ESPN there's that annoying ticker taking up the bottom of the screen. They are literally missing the big picture... Univision of course delivers on the comprehensive coverage but their image quality is worse and your Spanish? Well... ¿Se Habla Español? Well the game's on ABC today and they do full screen, so you'll try the English language commentary.

Sometimes you do want to hear the national anthems that the crowds sing, watch the players pretend to know the words, and soak in the tribal atmosphere. You've missed that today. Most Americans won't know what they are missing. Their country is becoming the Third World in the globalization sweepstakes, and some even seem proud about it... Well hopefully their team will do well in Germany and the underground football nation that I know lurks might manifest itself. Of course, I hope that Ghana will beat them handily, we need a little soul uplift.

Game on. Psyched.

Hmmm... the Paraguayan goalkeeper sustains an injury and has to leave the game.

The American commentator notes, "this is the second fastest substitution of a goalkeeper in World Cup history".

What the hell? You yell at the screen, "What does that have to do with the price of potatoes? This isn't baseball, football isn't a game of statistics."

Well anyway, experiment over. You promptly switch to Univision, they must be talking about things that matter. Anyway you'll need to know Spanish in Mexico, I mean California. (Justification: The Move).

It's a good game, England are looking great. Joe Cole terrorizing everyone, John Terry, Frank Lampard and Becks: the Axis of Solidity. Steven Gerrard, mon dieu. Peter Crouch: the hardest working man in the business... The whole team is shining and on the basis of this start, they could beat anyone. Meanwhile laptop on. Connect to Big Blue network, download latest build. Check rolandgarros.com.

Paraguay is keeping it close. Free kick. Beckham bends it...

"Gol! Gol! Gooooooooool".

Excitable announcer. Another one: "Goooooool".

Loud thumping overhead. A few shouts from neighbour. You shout. "Gooooooooooool".

Workers cheer from outside, must be Boston Irish or something.

"Here we go, here we go, here we go..."

Sounds of Wife stirring in bedroom...

"Gol! Gol! Gol!... Bravo. Goooool... Impressionante... Bravo... Gol... Mundialiasta... La pelota... Gol!..."

Remote. French Open briefly. Hmmm... Back to football. Start thinking about your glory days.

Laptop down. Pick up newspaper. Put down newspaper, match is too exciting.

Half time. Mexican adverts come on, skimpy dresses, rhumba dancing, eye-candy. Hmmm, you really need to learn Spanish... Still, remote: switch channel to French Open. Henin-Hardenne ahead. Whatever. Come on Kuznetwhatever. New York Times, now on page 4.

Oh! Laundry. Time to change the loads. Run downstairs.

Back upstairs. Hmmm. Hunger, food. Let's see...

Wife is up and about in the kitchen and looking grim... She's having breakfast but with that butter knife in hand, you need to tread carefully, you might get the macho treatment.

You try small talk and start muttering something lighthearted about the World Cup, widowhood and dilemmas... and begin to explain the various things on your plate, and talk about the match so far.

"You should eat", she says.

Good idea. More small talk... The food preparation business is not going too well, you turned on the kettle for the tea, but there was a noise on the TV, so you run there. False alarm, excitable commentator. You head back to pick up the toast. The broom is in your other hand. Start sweeping. Meanwhile more banter about glory days long gone...

You hear: "You're all over the place. You can't go on like this... not a bachelor anymore... A mess..." You nod your head and reach for the butter knife. Fridge. Marmalade. Milk.

The Wife is off in a huff (see also: evil eye). She comes back (avoids your eyes), grabs her laptop and heads for the bedroom.

Yesterday was your boycott day, it seems she's taken your message to heart and is boycotting you today.

Whatever. Justification: The Shankly Code (Shankly, Bill)

"Some people believe football is a matter of life and death. I'm very disappointed with that attitude. I can assure you it is much, much more important than that."

Second half is starting. There's the day job business. Food, laptop, cushions. Remote. Check French Open briefly. Switch. Watch.

10 minutes later, she shouts your name....

"What's up?", you yell between munches.

"I sent you an email".

Uh-oh. A deft multi-tasking effort now takes place.

• You put down the slice of buttered toast and marmalade and the bowl of Frosties (well Frosted Flakes in the US; the same Tony the Tiger, they're great!)
• You turn to the laptop, note that the build has long since finished downloading, start the install.
• Switch to Firefox and open up a new tab.
• You note that Peter Crouch just got a yellow card... Damn... England are looking like the most interesting team in the World Cup but yellow cards might be their downfall. Gerrard and now Crouch?
• You click on the Gmail icon in the browser toolbar.

You take a guess on the title of the email that should have shown up in your inbox:

Ultimatum.

Once again The Wife proves her fortitude and you read

From: The Wife
To: Koranteng@Toli

Subject: Fwd: The World Cup at the Enormous Room

Maybe you can see the match with some friends... Maybe I can meet their widows.

---------- Forwarded message ----------
From: Soul Africa Bulletin
Subject: The World Cup at the Enormous Room
To: Boston Crew

Greetings,

The Enormous Room is hosting live Telecasts of the 2006 World Cup every day for the month of June. The 12 pm and 3pm games will be shown live. The 9am games will be recorded and played after the 3pm games. The bar will be open, but the kitchen will not open until 5:30pm. Feel free to bring some lunch.

see you there.

You smile. Great idea, the Africans in Boston are rallying... Commerce mixed with community. You could do that tomorrow and for the rest of the month, you vaguely hope they have Wi-fi so you could perch there during the work day. The World Cup is a 9 to 5 occupation for a month every four years, you wish you could get paid for it. Still there's no time today.

You fiddle around, back and forth between the Bloglines and delicious tabs, copying and pasting links and titles of things you remember reading yesterday.

You compose the reply in Gmail and hit the send button

From: Koranteng@toli
To: The Wife (Disgruntled and long-suffering)
Subject: Widowhood

Great idea...

See also from my internet friend Noel and his wife Elissa.

Avoiding World Cup Widowhood

Avoiding World Cup Widowhood -- a Guide for the Uninitiated (pdf)

Close game so far.

Cheers.

Back to the game... Paraguay getting close. What gives with England?

Day job: not much progress. New York Times: nope, too tense.

The game ends, England wins... A Google search about your nagging concern "World Cup 2006 yellow card policy first round", nothing obvious.

Ah yes, remote; you switch to the French Open... Henin-Hardenne wins the last point and throws her hands in the air 6-4, 6-4. She deserves it although you prefer Kuznetsova. Better luck next time.

What do you do next?

You head into bedroom to face recriminations.

They are blistering as expected... "In good times and bad". You're in a good mood so you continue with the small talk: lots of things that you're juggling today, talk about the match.

It's not working... Whatever. More football banter... Still not working... more football banter, reminisce about distant glories....

But then she softens for a moment at your evident enthusiasm and asks:

"When is the next match?"
"I don't know, I have to check."
"12pm".

One hour to go before the next match...

Arrggh! You forgot the laundry. You turn. Vague thought: you can't do the groceries in that time... after the next match maybe.

You gather up the towels and such for the next load... You would have washed the sheets too but you don't fancy your chances of survival if you try to remove them while The Wife is lying in them...

You rush down to get to the laundry before that other desperado you met at half-time gets there (you recognized the type, he's also doing laundry and watching the game).

Made it... Arggh! You don't have enough quarters... remember that inflation calypso you were singing six months ago... prescience huh?

You run back up to get some quarters, you almost trip on the narrow stairs.

You steady yourself... there's no need to rush, nice and slow. Quarters. Back down the stairs.

You nod your head at the guy who arrives as you put the quarters in...

"Good game."
"Yeah, England might well win the whole thing."
"Those yellow cards though. Do they carry over?"
"I don't think so. Google it."
"Will do. Again."

You start humming Jerusalem as you walk slowly back up the stairs, it's been on your mind recently

And did those feet in ancient times
Walk upon England's mountains green

You break out in full song as you open the door to the apartment.

"..pleasant pastures seen..."

Hold on, the Belgian national anthem is playing on the TV, the trophy is being awarded.

You settle down on the sofa and take up the cool pad and the laptop

".. builded Jerusalem..."

Kuznetsova is praising Henin-Hardenne. Justine looks as cool as Belgian beer and chips.

In England’s green and pleasant Land.

End of hymn. You need some more music... but the remote for the Rotel amplifier is out of reach, and the universal remote that you have doesn't control said Rotel amplifier, they said it was universal.

That Rotel remote is the worst remote you've ever had the misfortune to use, you remember that you were going to blog about its design flaws at some point. Laptop, you open up Notetab, open toli-ideas.txt and write this nugget down. Later.

So you do the next best thing, you start to sing the next hymm in the Boycott Hymnal: To Hunt the Wren

How will you kill him?
With sticks and stones

You have 54 minutes before the next game: Trinidad and Tobago against Sweden... Now you're talking, The T & Ts are the Dream Team in the World Cup, there's a shortage of Trinidad T-shirts. Like the Ghanaians, Togolese, Angolans and Ivoriens, they are in it for the first time...

Oh yes order the cool pad, it worked fine. Lets see... Where's that credit card?

Portugal will be playing Angola somewhere near the town of Marburg. You take pride in that you see things that others can't. You hum along:

Hatchets and cleavers
Honouring his bones

You decide to do the dishes. Ah yes, the kitchen. Then sweep. Then you'll run to the convenience store across the street to get some blank VHS tapes talk with the guy about his relatives in Tehran and their preparations.

The question is what do you do when you come back?

You've just read the answer.

See also Ecstasy

File under: life, whimsy, Small Things, football, world cup, tradeoffs, dilemma, decisions, obsession, fever, attention, A.D.D., community, relationships, modernity, multi-tasking, juggling, humour, internet, web, conversation, fun, soccer, organization, preparation, observation, funny, Things Fall Apart, Thought Process, toli Risks: Day job, perception. Next: Ghana vrs USA

The REST Elevator Pitch

• The Pitch
• The Hard Problems
• The Sequel
• The Elevator Soundtrack

The Pitch

I somewhat share Ryan Tomayko's concern for a shorter hand language for describing REST (Representational State Transfer), but I believe that the REST elevator pitch is pretty succinct already. It packs a lot of insight into the web architectural style of which dissertations have been written. The language used in technical debates is always important and rather than devolving into the fuzziness of "highs and lows", I'll suggest here that, as a matter of advocacy, one should stick to the elevator pitch.

To recap, the REST elevator pitch is:

• Identification Of Resources
• Manipulation Of Resources Through Representations
• Self-Descriptive Messages
• Hypermedia As The Engine Of Application State

In its most common application, the pitch will lead you to the HUHXtable Quartet (HTTP / URI / HTML / XML) if we handwave away the additional content types that the web style enables you to negotiate. It is quite clear that applications of all kinds have been built on these fundamentals for both human and machine interaction.

The thing is that each plank of the pitch brings its own benefits, benefits that perhaps can accrue independently. Still you get the most bang for the buck at the internet scale by the principled combination of all of them.

In my advocacy I tend to start with resource identification as the most important plank. The reason for this is that everybody can understand the value of identification. My grandmother understands the value of a bookmark to my photos. Heck we are even seeing the social benefits of ostensibly selfish bookmarking. The importance of resource identification cannot be understated and it leads us to the primacy of the URI.

The second plank, manipulation of resources through representations, is the bread and butter of HTTP, where we have an evolving set of standard formats of hypermedia exchanged using a small set of verbs.

Unpacking the HTTP proposition leads us to the four horsemen of the web: GET / POST / PUT / DELETE

Of course you can do very well if you pick up only 2 of those verbs, GET and POST. The good Reverend HTTP is a pretty tolerant fellow and won't begrudge those that don't believe in the rule of four, although in admittedly imperfect analogies, there's CRUD (Create / Retrieve / Update / Delete) in the database world and, as far as this layered internet goes there's TCP / IP / Datalink / Physical Layer (with say Ethernet or "Wi-Fi" 802.11b/a/g)

On the other hand, if you want to be a good citizen in the town of Deadwood and indeed if you want to survive in the wild west of the web, you shouldn't abuse HTTP. HTTP abuse leads to user confusion, headaches for systems designers and a tragedy of the commons. I consider HTTP a deliberately minimalist compromise, laissez-faire distributed computing if you will.

In social settings making your intentions known can help smooth interactions. We may start with small talk but we eventually manage to discern where others stand - well most of the time at least. We all operate with imperfect information but being straightforward is often a great policy. I'm sure there's some game theory or behavioural economics that can point to the value of transparency. Perhaps it is trite in light of Machiavelli and Sun-Tzu to believe that disclosure is the best policy but at least in markets transparency tends to be the font of aggregated wisdom. On the internet scale, this translates into the notion of giving visibility to intermediaries. Arguing again by analogy, the internet is an agreement, a network of networks. You can do whatever you want on your network but to interoperate with others, a small set of primitives, the TCP/IP standards in this case, have been agreed upon. I would suggest that the web style is similarly such an overlay system. REST is an architectural style which by principled design, is optimized to lower coordination costs.

Acknowledging the benefits of idempotency, of doing things safely, will lead one to making sure the use of GET is safe. Idempotency is not just about safety however; in clearly signaling your intentions, it is also about replayability. Thus idempotency is not just about the GET method. That is the wider argument for also using that oft-neglected duo, PUT and DELETE. Tunneling everything through POST (and the completely aberrant case GET) may be convenient but it adds unnecessary opacity and unpredictability about one's application. Unpredictability in the world leads to invasions and worse I might add. The use of those four core HTTP verbs helps intermediaries understand and participate more fully in the ecosystem.

The last two planks of the REST elevator pitch, self-descriptive messages, and especially that last one, hypermedia as the engine of application state, are attempts at addressing the issues of state, caching and evolving systems amongst other things.

Now of course in the preceding paragraphs, I've handwaved away entire dissertations that have been written about architectural styles and systems design, tomes written with language more precise and concepts more subtle than I've outlined. Good samples and running code are often also a determining factor in which style or application is adopted thus the view source imperative is also one of the reasons that web has caught on so quickly.

The Hard Problems

I've recently been thinking about defining the hardest problems I've encountered in software engineering, my cursory top 10 list:

• State
• Caching
• Latency
• Concurrency
• Search
• Metadata
• Persistence
• The Holy Grail Of Extensibility
• Structured data
• Character encoding

Now I'm not a database person so I handwaved away all of those data peoples' worries in one word: persistence. Of course I should probably add a few more issues and indeed you probably have your own notions. Indeed I settled just two days ago on those last two, structured data and character encoding, when I characterized them as being the gruesome twosome of computer science. Perhaps also there's the issue of discovery and bootstrapping of a system but that could be considered implementation details. There are those who mention security and reliability as other hard problems and they certainly are. Still I'll also handwave those away not as technological issues but as transaction costs; the economic benefits of ubiquity and leverage are key here. It seems that humans are quite prepared to tolerate gremlins and parasites in their systems (social, biological and technological) in moderation of course.

What is interesting is that almost all of these issues are important even if you aren't dealing with distributed computing. On the internet, which is all about distributed computing however, these are crucial problems. Now addressing these problems is a pretty tall order I must admit, but it seems to me that the web style has concrete answers to almost all of these constraints. Furthermore REST also offers a couple of those very valuable system characteristics: resilience and adaptability, almost as externalities.

Search for example seems to be addressed by valuing the importance of resource identification, the URI, that leads to PageRank and other algorithms. If you start with a viewpoint that URIs are cheap, and if you model your resources appropriately, you can deal with concurrency quite reasonably. State, caching and latency are all to do with performance which is always a bear. To that I'd argue that the commerce that is taking place daily on the internet seems to be a good indication that things are acceptable even if they could be improved. Metadata is the eternal headache of course but HTTP will give you headers and soul to help a little.

Discovery is addressed by URI as identification, the notion of hypermedia (either link headers or references in the media) and perhaps the current best practices of introspection resources. Persistence and structured data, I'll argue, are being addressed, warts and all, by the relational database, the seemingly-unstoppable spread of XML and, I believe, the current ascendancy of feeds. On this last subject, the wiring of the web, I am cautiously optimistic that the Atom store dream could be an answer; i.e. the combination of feed format (say Atom/RSS) and a wire protocol - which perhaps the Atom Publishing Protocol or similar could be. On the question of extensibility, last year I started a response that I felt was needed due to Dion Hincliffe's unbelievable assertion that "extensibility was the Achilles heel of REST". It always takes me a year to respond to minor footnotes but if there's one thing I'll do in the next few months, I'll be sure to write about REST and the Holy Grail of Extensibility.

But anyway, that is getting ahead of myself. I've been told to save my musings for "the book" or to stick to writing the running code that will "show, rather than tell" yet I keep falling for this web as conversational engine. Still there are undoubted social benefits of these exchanges and perhaps conversations like these are another virtue and externality of the web style. In any case, consider this my long winded response, Ryan: in matters of technology adoption and systems design, let's stick to the elevator pitch.

Further reading:

• REST - the web style
• A REST Intervention
• On Iframes, WSRP, REST and Portals
• The Unloved HTML Button and Other Folktales
• The Gospel of REST
• The Economics of REST

The Sequel

[Update - March 27, 2006] It seems as if everyone is getting into shaping the pitch and the language has been quite interesting.

• Danny Ayers remarked that we should go back to the source and points at Tim Berners-Lee's pitch from last year

  Web architecture 101

  • Things are denoted by URIs.
  • Use them to denote things.
  • Serve useful information at them.
  • Dereference them.

  That indeed is about as brief a pitch as some executives will be able to handle and it covers the essentials.
• Tim Bray's pitch is fairly pithy too, and for the last plank he uses

  You expect to ship a lot of URIs around in the bodies of requests and responses, and use them in operations that feel like link following.

  Now that's quite a mouthful in a presentation but it works fine in an elevator. I think "dereference them" is more terse and captures much of the same insight.
  
  As an engineer who is interested in precision in language, I tend to prefer Roy Fielding's formulation of "hypermedia as engine of application state". It's short and alludes to both the implementation and the area of focus of the web style. But your mileage may vary and I think it depends on the audience. We should be interested in a pitch that works because the advocacy struggle isn't over even if some are already thinking about the future issues. In this light, it was good to see Joe Gregorio again emphasizing the Show me the code route he embarked on last year. That View Source Imperative is the secret ingredient as far as adoption goes.

Note that everyone seems to conform to the Rule of Four as far as bullet points in the pitch go. Interestingly enough, Roy Fielding used to go with a five point pitch until he merged what were his previously separate definitions of "resource" and "URI" into the phrase "Identification Of Resources". I've proposed my own four point plan as a model for ArRESTed Development or The Low End Theory.

I concur of course with the endorsement of the formulation of REST - the web style and not just because I seem to have juice (of the google flavour) on that front having internalized that phrase long ago in my interventions, but because it gives us a tag, REST, combined with a catchphrase. As we know, every movie needs a tag line. Especially in Deadwood: "6 million ways to die, choose one". That is the B-movie of distributed computing. We want to move beyond grindhouse pulp fiction and get some of those glamourous, golden Hollywood trophies. And if that fails there's always the Gospel of REST.

The Elevator Soundtrack

• Outkast - Elevators (Me & You)
  The chorus of this laidback piece of Atlanta folklore could well be a stand-in for the inclusiveness of the web style and its architecture of participation.

  Me and You
  Your Momma and Your Cousin Too
  Rollin' Down The Strip On Vogues
  Comin' Up Slammin' Cadillac Doors

• [Update] A hat tip to the good doctor, Ernie Prabhakar, who points to a real life Huxtable Quartet. When I first started using HUHXtable, I was thinking of the Cosby Show and of comfy sweaters, thus it's great to hear that the Slide Huxtable Quartet is itself a tribute to that show and to the "Play It Again, Russell" episode in which Cliff's father, trombonist Russell "Slide" Huxtable (Earl Hyman) hosts a jam session. REST has even got a house band.
• Miles Davis - Ascenseur Pour L'Echafaud
  I've always loved Miles Davis's cool soundtrack to one of the great film noirs which saw a great print released last year. It's atmospheric and gets the job done - and with verve. I am always upset that ascenseur is translated as lift rather than elevator which is more heady to my ears. I'll conclude by suggesting that the web style will save you from heading up the Elevator to the Gallows.

File under: technology, rest, systems, software, design, architecture, advocacy, leverage, adoption, composition, tradeoffs, http, uri, xml, html, atom, web, language, strategy, toli

On Iframes, WSRP, REST and Portals

• On Prescience
• On Iframes, WSRP, REST and Portals

I'm still getting lots of good feedback to my presentation on REST - the web style (background) which I will summarize shortly. One of the more curious responses was to something that I didn't even dwell on in the presentation; indeed I think I skipped past it in my concern to get the big picture articulated. I suppose it was the proximity of yet another acronym, WSRP, to a couple of slides about complexity in the IBM technology stack, and a very public case study bemoaning the fact that Websphere Portal only added bookmarking after 3 years that raised a little concern. This was part of my subsequent response to one of those comments, slightly edited for clarity.

On Prescience

I fully agree, we should celebrate any and all who contributed to us internalizing the web style in WebSphere Portal. We should be very explicit about the pain we and our customers suffered and the evident gains that came once we learned our lesson.

The notion that it was still a struggle to get that simple feature (the ability to bookmark) included in the WebSphere Portal 5.1 release is actually a commentary on our previous attitude to the web style.

I would add to the list of those to be celebrated, those screaming Cassandras who were incredulous that we could ship a web product while ignoring url addressability and even tried to prototype some rudimentary addressability and sneak it in back when we had commit privileges to the core. If only we had had more nerve or had been able to better communicate the importance of this point... I know it normally takes 3 releases for a product to become useful, but sometimes magic can happen in the first release and with that comes thought leadership (Glory) and perhaps also some money (Gold).

On Iframes, WSRP, REST and Portals

Leading with the iframe invocation argument was always the weakest argument of those who I'll cast as the "K-stationers" in the early days of WebSphere Portal. After all, and like you note, even though iframes may provide

• easy integration of existing content
• multi-threaded download in the browser to lower the latency for the user
• caching closer the client (indeed in the client)
• offloading the portal by removing a layer of indirection in the portlet -> portal server -> client browser route
• introducting the possibility of moving aggregation to the client (leveraging Moore's law and bandwidth increases to the client)
• further recasting the "Portal Server" to a "Portlet server"(in other words there should be no difference between a "remote" and a local portlet) etc . That is the lesson of uniform interfaces in the web (e.g. URIs)

Now that's a pretty strong "weak argument" but we should acknowledge that Iframes also have downsides. Iframes mess with user expectations especially with respect to focus and some browser conventions are a little upset by them (e.g to bookmark, you need to right click on the frame in question). Browsers did solve the issues with the navigation history after a few years, but there was a little confusion in the interim with back button and refresh etc).

6 years on, I hope I have learnt to recognize the stronger aspects of an argument about systems design. What we didn't recognize or adequately evangelize was the value of the other aspect of an approach that more fully embraced the web, namely:

Basing the application semantics of the portal directly on URIs and the use of those 4 verbs that are the core of the web.

To explain, HTTP is an application-transfer protocol. It is something that works at the application layer. It has its native notion of how CRUD like operations are done (GET, POST, PUT, DELETE).

The REST proposition again:

• Identification Of Resources
• Manipulation Of Resources Through Representations
• Self-Descriptive Messages
• Hypermedia As The Engine Of Application State

I haven't kept abreast of WSRP in the past 5 years and thus my characterization of it was perhaps a little careless, but that's what you do when you make a presentation that borders on the provocative. In mitigation, I'll confess to being what I've termed a Layer Stripper.

Let me handwave a little... It strikes me that building an application protocol with CRUD like functionality that will typically (or even solely) be used over HTTP can lead to a little impedence if one is not careful.

To take my Technical Arteriosclerosis Terminator scalpel to WSRP, I would only ask:

• Do the CRUD like operations in WSRP map one to one with HTTP's native semantics? In other words, is the moral equivalent of a PUT in the WSRP world implemented as a PUT when the "transport" is HTTP?
• Is this true of at least those 3 verbs at the core of the Web (GET? POST? DELETE?). (I'll assume that WSRP adds perhaps more verbs in its applications semantics).
• Are the security primitives going to be leveraging HTTP's native security features or are we rolling our own?
• Are there any other "transports" other than HTTP? Is there a CORBA mapping for WSRP?

RFC 3205 On the use of HTTP as a Substrate should be required reading here.

I'll suggest that if we were starting from scratch we might do the following

• Start with Resource Modeling and ask: what are the core resources that need to be identified in a remotely invoked portlet?
• What representations need to be returned? For this we'd probably pick some standard Portal XML vocabulary or, for browser rendering, an XHTML format, for pervasive rendering some other Markup Language
• What are the operations that need be performed on said resources?
• What HTTP verbs are appropriate for each operation when we manipulate those resources?

Joe Gregario's Show Me The Code column has been going through this exercise with the example of a bookmarking service - well worth reading. A remote portlet may have more complex semantics but one should go through this to clarify our design and architecture. I assume that WSRP implementors went through such a process as that spec was standardized.

The result would be something like simple URI commands returning representations and manipulating them using well-worn HTTP semantics. I very much hope that is what WSRP has evolved into. We'd get:

1. Visibility to HTTP intermediaries, first the caching proxies in the web sense. (like the page caching in the portal)
2. Since we'd be using URIs, someone may think up new uses for our remote portlets and be able to easily embed them in their application through simple hyperlink and the use of the appropriate verbs etc. Third party Glue Layer people could "remix" our portlets through pipelining and filtering or whatever else those people do (I'll note that IBM recently bought Gluecode)

With this approach there is no API per se, the interface contract is explicitly manifested in the exchanged hypermedia and associated operations on the resources.

"What? No API?" "This RESTful stuff has no substance". "Where is the value add?"

That indeed is the paradox of the web style. The "API" is typically HTTP/URI/HTML/XML.

The fourth plank of the REST proposition is a difficult thing to internalize, I certainly couldn't express it adequately 6 years ago.

"Hypermedia as the engine of application state"

Ponder that for a few weeks.

[Update] James Snell adds: "HTTP is the programming model".

Some have suggested that one would additionally require some service description language, perhaps WSDL, for such a service. On that, the jury is still out. In the example I highlighted in the presentation, Google Maps didn't publish any WSDL. Craigslist didn't publish any WSDL. They simply had a clean URI api with well-defined parameters that were obvious to any developer with a week to spare and idle curiousity satisfied by the View Source impulse. It was obvious what verbs to apply: POST or GET, PUT (they don't delete their maps, but if they did, that is how one would proceed). Third party intermediaries simply figured out that url hierarchy and the associated verbs, the identified resources and what formats the representations were retuned in. Then they manufactured serendipity. Now there is no binding contract and things can get broken at any time but it wouldn't be in Google's interest in their competition with Mapquest or Terraserver to break people that compose applications on their platform and brings eyeballs and mindshare to their company.

This then is my argument for changing the frame of the debate:

There's a complexity and layering argument that naturally falls out of the REST viewpoint which should guide the applications that one builds.

The web is about identifying important resources and exchanging representional state. There are certain constraints that are made to enable global scope and evolution. Being on the web, is being an active participant in this scheme of things.

Identifiers lead almost to having the location field as the command line.

Resource modeling as your starting point sets you in direct consonance with this notion and exposes you to ease of composition.

e.g. Jon Udell's Library Lookup project

An information architecture that starts with hypemedia lends itself to the construction of simple interaction designs for both humans and machines, and there are huge amounts of tools readily available for this.

The question is then one of leverage; leverage in economic terms is all about making externalities work for you. The endpoint of this approach to system design is what I call a virtuous cycle of managed serendipity.

One response to this piece was that actually WSRP stood up quite well to those questions I had hand-waved in its direction, apparently it was not too complex, it addressed wider issues and use-cases etc. I think that is great and hopefully the leaks have been plugged in that spec so that it can be mapped reasonably to HTTP; I guess the argument is that it is not an unnecessary layer. I'm still unclear if WSRP is ever used with a "non-HTTP transport" or security, I'll dig into that at some point. In any case, the point of my talk was the same scrutiny should be brought to bear on all of IBM's technology stack and unnnecessay layers shed and/or leaky abstractions plugged to make them work better with the web style.

A later follow-up, privately-addressed, asked:

"Isn't a "portlet" fundamentally a presentation-level object? Why is the concept of "portlet remoting" not considered an oxymoron? Shouldn't we be talking instead about the simple expression of web services as data (with, perhaps, media-type detection as an enabler of polymorphism"

There was lots more and quite fulminant at that, I'd have to say that's all true and expressed more concisely than I did. It's good to know that there are like-minded people around. I didn't mention content-negotiation in my response but that is another aspect built into the web style that can be leveraged but that is constantly being reinvented at higher levels and layers. There's lots more to say but that's the lay of this technology world... In evangelism the first step is to get people sensitized, after that it's best to proceed one argument at a time.

---

P.S. I've been told there's been too much technology toli of late so I'll try to push some literary, musical or African toli to the head of the queue, it can be more fun and oftentimes more rewarding.

File under: technology, web, REST, systems, design, architecture, tradeoffs, adoption, leverage, composition, iframe, wsrp, WebSphere, ibm, portal, portlets, aggregation, software, complexity, uri, http, xml, html, xhtml, lotus, IBM, toli