Paul gets it
(link) [del.icio.us/distobj]
Ted follows up on the discussion over at Steve Vinoski’s blog that I forgot to point to. I hate having the last word, because I don’t know if that means that Michi got my point or not.
(link) [del.icio.us/distobj]
OMG, this is hilarious.
(link) [del.icio.us/distobj]
Dims and Mark hack an API
(link) [del.icio.us/distobj]
Some musings of mine on OpenDoc and W3C CDF
(link) [del.icio.us/distobj]
I’d forgotten about this excellent piece by Paul Prescod.
(link) [del.icio.us/distobj]
Some REST push-back. Seems more a complaint of Flickr’s API than REST itself though.
(link) [del.icio.us/distobj]
Three years and two months between drafts; a new record?
(link) [del.icio.us/distobj]
“The number one reason people begin blogging is to establish themselves as a visible authority in their field” Huh. That’s why I do it, but I would have thought that reason to be well down the list.
(link) [del.icio.us/distobj]

The more that two parties agree upon, the more that can be accomplished between them without additional coordination.

Additional coordination is expensive. It not uncommonly requires years of standardization and years more to deploy the new software to support it. Therefore, if we can leverage existing deployed agreement, that’s always best…

If two parties agree to communicate via TCP/IP, on some specific port, ad-hoc integration capabilities are limited to sending and receiving bits reliably between two points. Want to exchange data? Want to invoke a method? Sorry, additional agreement is required.

If two parties agree to communicate via the common use of SOAP-over-HTTP, ad-hoc integration capabilities are limited to remote method invocation with standardized faults in response. Want to invoke a method? No problem! Want to exchange data? Sorry, that requires additional agreement on a set of methods that facilitate data exchange.

If two parties agree to communicate via HTTP (or other transfer protocols), ad-hoc integration capabilities include data exchange.

… and so on, and so on, up the stack.

I’ve found that placing new technologies in the context of this coordination-centric view of the world as an excellent litmus test for the potential success of those technologies.

It also helps me to evaluate some design choices in large scale systems where an existing system is being “reused”. For instance, I consider the Web services notion of “protocol independence” to be prima facie a bad idea because it knocks us down a notch in terms of what can be coordinated a priori; whereas without tunneling we can use HTTP for data exchange, with tunneling we can only use it for method invocation.