A post in today’s NewsScan triggered a revelation: all standards whose acronym begin with the letter ‘S’ are likely to become hulking, bloated messes which nobody can bear to use.
First, the set-up: I am currently working on a project to integrate with a client using SOAP to get data. However, the interchange actually uses none of SOAP’s functionality at all — we send them is simply a two- or three-digit integer wrapped in some verbose XML (160 bytes worth) which could just as easily be sent as an HTTP request parameter; they send back a SOAP envelope with an empty SOAP header and a SOAP body which simply contains an XML document. After reviewing the available SOAP toolkits for Java (and poking around a bit at some for Python), I opted instead to use java.net.HttpURLConnection I’m not ashamed to admit that I build the SOAP request to them with string concatenation, write it to the
HttpURLConnection‘s output stream, and process the returned SOAP request using DOM4J and ignoring the SOAP envelope parts. Actually using SOAP here would bring me nothing but headache.
So this led me to trot out my old aphorism: SOAP is to some future interchange protocol as SGML is to XML. Both of these “S” standards attempt to do so much that they result in an insanely complicated mess that can only be tolerated by giant corporations (“BigCos”) and bureaucracies on the order of the US government. HTML claimed to based off of SGML, but erred on the side of being too permissive, leading some people to take a critical look at SGML and pare it down to the much more manageable XML specification. I suspect SOAP will see the same treatment sometime in the next few years. Anyway, on to the NewsScan story:
RIVAL INSTANT MESSAGING STANDARDS FACE OFFTechnology giants like IBM and Hewlett-Packard are squaring off for the next skirmish over the technical standards. This time the battleground is instant messaging, which is rapidly making inroads into the corporate suite. The two major standards are SIP/SIMPLE (session initiation protocol for instant messaging and presence leveraging extensions) and XMPP (extensible messaging and presence protocol). Microsoft, IBM and Reuters, among others, are backing the SIP/SIMPLE standard, while XMPP’s advocates include France Telecom, Intel and Jabber, a developer of enterprise IM software. Hewlett-Packard recently threw its weight behind XMPP by developing an instant-message server with Jabber, and other Jabber customers include BellSouth, AT&T and Earthlink. HP Services manager Michael Dang praises XMPP’s fully developed design: “Put it on a cheap Intel box and we can instantly communicate.” But SIP/SIMPLE’s backers say the protocol can serve as a basis for other systems besides just messaging. “It was important for us to have a broader architecture than just something based on instant message,” says an IBM Lotus marketing manager. Meanwhile, some analysts are predicting that SIP/SIMPLE, although widely regarded as the inferior standard, will win out, largely because of its heavyweight support. “Most people will be moving toward SIP/SIMPLE simply because Microsoft and IBM use them,” says market researcher Michael Osterman. (Wall Street Journal (sub req’d) 16 Jul 2003)
Notice the initial letters of the two competing standards: SIP/SIMPLE and
XMPP.
You read the description of SIP/SIMPLE and you get the sense that, once again, the big guys want to boil the ocean. I’m not qualified yet to push my aphorism to embrace these competing instant messaging standards, but it does seem suspicious the way these acronyms play out…
XMPP.
You read the description of SIP/SIMPLE and you get the sense that, once again, the big guys want to boil the ocean. I’m not qualified yet to push my aphorism to embrace these competing instant messaging standards, but it does seem suspicious the way these acronyms play out…
Unfortunately, I think Joe is right about this. I use Jabber (XMPP) for most of my IM needs and we’re seriously considering using it at my office for internal messaging. The main reason for that is the ability to program custom extensions, since many of the server and client libraries that speak Jabber are open source. To get the kind of things Jabber can give us — SSL, server-side message logging, etc. — you need to buy “enterprise” versions of most other messaging products.
But, most typical uses of Instant messaging (whether humans are involved or not) and presence are gravitating toward SIP. For instance, iChat AV uses SIP packets for this.
I guess as long as there’s an open, extensible SIP server and a Java or Python client library for it, it really doesn’t make much difference to me…