Microsoft - Ahead of It's Time?

I happen to agree with Dare (mostly) on the point about MS and recent innovations -
Microsoft and Innovation: Always Ahead of It's Time or Bad Marketer?

"After watching a number of recent trends in the software industry I've been struck by how many of them were originally started by Microsoft but later abandoned only to be picked up by the rest of the software industry a few years later."

However, I don't think the Web APIs trend was really started from Microsoft. My exposure to XML, syndication and DHTML started at the same time as when Microsoft was building out those things Dare mentioned (I even worked at one of the fad 'push' companies) - but I don't recall Hailstorm as a leading edge of Web APIs. Most tech companies and independent technologists were doing that on their own - I even architected the main product of one company to use Web based access and XML as the root of it's remote API back in 1999.
Of the three examples Dare mentions, Microsoft demonstrated and delivered advanced concepts in the desktop arena, but not in the server space. It may sound like a cliche, but that's my recollection.

Amazon turns 10

Amazon is 10 years old this week - and two great musicians (Bob Dylan and Norah Jones) are going to give a show! But I'm going to be out of the country :(

This NYT article an Amazon is amusing - the 'analysts' still want Bezos to quit:

"But in general, the practice in the technology world is to bring in an experienced manager who can earn Wall Street's respect, either shortly after the founding of a company or just before it goes public."

This is kind of funny advice, since there is no other place that has the experience that Amazon needs to run the business. And Amazon historically has worked to earn the respect of customers - I think Wall Street should go earn their own respect. Also, the practice of bringing in new management - in general - also has happened just before a company vaporizes. Coincidence? I think not.

Carlyle's Sound Advice and REST

Benjamin Carlyle has this to say when comparing object-oriented programming with REST architctural style:

"On the other hand REST says that the set of operations you can perform on resources should be almost completely uniform. Instead of defining new operations, REST emphasises the creation and naming of new resources. As well as limiting verbs, REST seeks to reduce the number of content types in play. You can picture REST as a triangle with its three vertices labelled 'nouns', 'verbs', and 'content types'. REST seeks to push the balance well away from both verbs and content types, as close as possible to the nouns vertex. "

This is not accurate - REST actually drives toward increasing content-types. Not necessarily maximizing, but definitely opening up the space of possibilities. So I would say that REST seeks to push the balance away from verbs and as close to the edge of nouns and content-types.

Also this:

"REST says that the namespace should be king. Every object that should be contactable by another object should have a name. Not just any name, but a globally-accessable one. If you push this to the extreme, every object that should be accessable from another object should be also accessable from any place in the world by a single globally-unique identifier. [...] REST provides each abstraction through its heirarchical namespace rather than trying to hide the namespace. Since all accessable objects participate in this single interface, the line between those objects blurs."

This definitely is key to the REST architecture. However, REST does not have a heirarchical namespace. Neither does HTTP. They only have identifiers that are opaque to the client. Also, since resource have a single interface, the line between these objects isn't so much 'blurred' as it is unnecessary.