Book Review: "Protocol" by Alexander Galloway, MIT Press

Stu Charlton recommended this book to me to read, as a way to explain the freedom of the Net that paradoxically stems from strict controls, i.e., protocols.

I ordered the book straightaway. It arrived yesterday, and I read it last night in a single all-night session. Not that it was unputdownable. Far from it (and more on that in a while). It's just that my sleep habits have become rather bizarre and all-nighters are now the norm.

The book makes a few interesting and important points, and the fundamental one is about "how control exists after decentralisation". That is in fact the book's subtitle. In contrast to earlier ages, when control was more direct, today's systems rely on protocols, which all players have to accept to even become part of the system. Protocols are highly formal. They are pervasive and must be internalised by all players (my words). Thus, even as systems become distributed with no central authority, the control systems do not disappear but manifest themselves as protocols. The contradiction with protocol is that it has to standardise in order to liberate. It has to be "fascistic and unilateral in order to be utopian".

There are interesting sections on the Internet's procotols, the hacker culture, cyberfeminism and "Net.art".

I like the idea that pro-protocol behaviour (giving out technology even to competitors) wins out over proprietary behaviour, which explains the success of Open Source. There's also the intriguing thought that protocol has a contradiction at its core, that "in order to be politically progressive, [it] must also be partially reactionary."

I learnt a few interesting bits of trivia, and also some important (?) subtleties, e.g., the difference between "decentralised" and "distributed" in the author's view. "Decentralised" means having many hubs as opposed to having just one hub, as in a centralised system. A decentralised system still differentiates between hubs and leaf nodes. Leaf nodes can only connect to hubs, not directly to one another (hubs are connected to one another). A distributed system, on the other hand, has no "hubs" at all. All nodes are equal and any node can connect to any other. It is the distributed system that Galloway argues requires (or manifests) protocol.

Another interesting insight the book offers about the web is how there are simultaneous and opposing forces at work. The web itself is distributed, but DNS is hierarchical. While content on the web cannot be deleted by a centralised authority, it can be rendered inaccessible by merely changing some DNS entries at the root level. An entire country can be made to "disappear" from the web through the mechanism of DNS.

Now for the criticism.

Alexander Galloway reminds me of the "literary intellectual" of C.P. Snow's "The Two Cultures", the kind who Snow says "took to referring to themselves as intellectuals when no one was looking". His style seems intended to impress rather than inform.

I believe his entire book (all 246 pages of it) can be expressed in about 10 pages or fewer if translated into English from pseudo-intellectual gobbledygook.

Some sections are almost verbatim reproductions from the publications of Karl Marx, Gilles Deleuze and Michel Foucault, with interminable sequences of quotations therefrom. It reminds me of the old joke that copying from one person is plagiarism, while copying from many is research. This book is full of research.

Alas, he seems not to understand the power of protocol himself! In the conclusion, he says, "The fact that Microsoft has not yet replaced TCP/IP with a commercial product of its own is one of the miracles of computer history. Chances are this will happen very soon". Really!? And this right after the section on speed bumps when he defines protocol as something that appeals not to the mind but to the "body", as something that one is inherently forced to do, not something that appeals to the intellect or is applied as overt force. Replacing TCP/IP is something Microsoft simply cannot do because it will run afoul of "network externalities". That will be virtually impossible for Microsoft to pull off, and not because someone is standing with a gun to their head either.

You will feel right at home reading this book if you understand the following words and phrases (Warning: even if you think you recognise a word in this list, rest assured the author uses it in a way you may not recognise):
semiotic, periodization, machinic, panopticon, dispositifs, immanent, au milieu, rhizomatic, territorializing, phenomenologically, radical dislocation, phoneme, hegemonic, protocological, affective, imbrication, anti-anthropological, autochthonic transformation, depresentify, plenitude, discursive, subjectless patterning, dividuals (no, that's not a typo), prefigure, reification, commodity fetishism, camera obscura, dialectical method, montage, vitalism, second-order system of signification, patina, vitalistic discourse, self-aestheticization, epistemological inversion, social hieroglyphic, meme, labile, anti-entropic, ontological rub, hyper-Platonic, hypertrophy, elided, juridical, autodidact, hyperlinguistic, protean, apotheosis, machinic phylum, valorizing, libratory, elliptical.

I notice that many of these words appear in quotes from other researchers. Perhaps that was the purpose of the quotes, to add to the book's impressive vocabulary. Thanks, Dr. Galloway, you've impressed me - NOT. An author can choose to either communicate, or to drown the reader in verbal garbage. You've done the latter, and wasted 6 hours of my time in the process.

Call me lowbrow, but I'm definitely of the "my 4 year old could do that" school of modern art appreciation. I'm impressed by Michelangelo and underwhelmed by Picasso. Someday we'll all learn about how Picasso laughed himself to death. And I suspect Alexander Galloway is similarly having a good laugh at his readers' expense.

The Good in WS-* (Update)

See post below for my initial, entirely positive reactions to Stu Charlton's critique of the WS-* family of Web Services technologies.

Now for some qualifiers.

I wonder why Stu didn't include SOAP in the list of "good" technologies. I don't mean the overloaded meaning of SOAP (the RPC style of usage, for example), but quite simply the SOAP message, the envelope. All the WS-* stuff is useless without the primary vehicle of the SOAP message which carries them from endpoint to endpoint. One has to admit there is a certain elegance in its simplicity, analogous to the humble IP packet that is the workhorse of the Internet (read more here).

The envelope has just two parts - a header and a body. All the domain-neutral WS-* tags that Stu talks about go into the headers. The body contains domain-specific XML payloads that hopefully conform to some defined schema. Unlike with the TCP stack, where packets are recursively enveloped within other packets (e.g., HTTP inside TCP inside ESP (IPSec)), ultimately being packaged inside IP for transport over the "wire", SOAP has a single-level layering approach. All quality-of-service tags represented by the WS-* standards are placed on a co-equal basis within the SOAP header, which is OK because they largely represent orthogonal concerns. (There is still some interdependence, e.g., you can't just have WS-Security if you're using WS-ReliableMessaging; you need WS-SecureConversation as well, because the system now has to be cognisant of conversation state.)

The SOAP message represents, at once, a domain-neutral wire protocol that supports any application and a domain-specific application protocol that defines the verbs, nouns and conversation grammar of a particular application domain.

I see both SOAP and REST as ways to move domain-specific XML documents around. From that angle, they're both defining a core application wire protocol that can support any application domain (HTTP or SOAP-with-headers). Each application has to define the nouns, verbs and conversation grammar appropriate to it and exploit this "wire protocol" to move the XML noun payload in the context of an interaction verb (GET/POST/PUT/DELETE being pre-defined within the REST wire protocol or a bespoke one for SOAP/WS-*) and thereby build up a domain-meaningful conversation, what the REST folk call a state machine and what the SOAP/WS-* folk call a process.

I think we're all in violent agreement over the need to move XML around in a series of interactions that occur within the larger bounded context of a state machine or process. As has been said in many other contexts, our similarities are greater than our differences, so let's not read too much into the SOAP-REST debate.

William Vambenepe has more to add on this. It's an earlier post, but very topical. There's a lot more promise in SOAP than most of us realise, and the standards themselves sometimes belie that promise. Read William's post to see what needs to be fixed, hopefully in the next version of the WS-* standards.