Herewith, a rant: multiple transport bindings considered harmful.
I still hear this and it's getting increasingly annoying. People consider it a good thing for a standard to be able to run over HTTP, BEEP and something else. Has this ever proven to be a good idea? Layering is good for other reasons, but not because it gives implementors a choice that leads to interoperability failure in many cases.
Is it a failure on the part of the designer to understand the usage characteristics of their protocol, and successfully map that onto TCP (connection-oriented), HTTP (stateless respond-and-forget) or something else?
SOAP is supposed to be transport-independent and offer choice, but as I overheard last week, there's a reason they call it web services. And the ultimate in multiple-transport wankery: I once heard somebody propose a schema which they said would run over SOAP or HTTP.
Are there use cases I'm unaware of, where this has been a really good thing for some standard?
2 comments:
Hey Lisa,
What about this protocol named XMPP, with a TCP and an HTTP binding? I'm sure you've heard of it ;-)
Slightly less flip than Ralph, there are lots of working implementations of BOSH, the HTTP binding for XMPP.
http://xmpp.org/extensions/xep-0206.html
Post a Comment