With a Whimper Instead of a Bang

2nd of June 2016

The 31st of May 2016 will be the final day that Teletext will be in use at the VRT, which is the public TV channel in Belgium (the Flemish variant). For me, this does not mean a lot, and so it doesn’t have any impact, since I never used it in my life. The reason given by the broadcaster is that the focus will be put entirely on the digitization of the public network.

I associate the decommissioning of an entire line of communication with customer facing to have a hefty transition period and a solution to take over the customer needs it covers. But in this case, the plug was pulled, and nobody ever looked back. Not even a proper funeral or any such measure. Only few interviews with long time customers published on their online presence. And for those unlucky few, a hole in their daily lives has been created that will have to be filled with other experiences. 😁


For those unfamiliar with the protocol, Wikipedia states the following about Teletext:

Teletext (or broadcast teletext) is a television information retrieval service created in the United Kingdom in the early 1970s by the Philips Lead Designer for VDUs, John Adams. Teletext is a means of sending pages of text and simple geometric shapes from mosaic blocks to a VBI decoder equipped television screen by use of a number of reserved vertical blanking interval lines that together form the dark band dividing pictures horizontally on the television screen. It offers a range of text-based information, typically including news, weather and TV schedules. Paged subtitle (or closed captioning) information is also transmitted within the television signal.

It got me thinking of all these other communication protocols that have gone the way of the dodo, or are at least transitioning towards their demise at a crawling pace, desperately clinging to the sometimes perceived importance they once had. Several of these have even been favorites of mine at the time of their use.

Speaking about clinging to life, the Internet Relay Chat (IRC) protocol comes to mind. No longer of any relevance, but if we regard the usage statistics, there is still a faint heartbeat. The graphs over at efnet still show a daily count of 20.000 users. Not comparable to the heights of its glory days, but at least someone still cares enough to keep it up and running. An article of 2012 called “IRC is Dead, Long Live IRC” indicates that IRC has lost 60% of its users over the nine years leading up to its writing.

Then there’s the protocols that got replaced without the world (or at least the non-tech part) even noticing. Take the HTTP/2 protocol for instance. It replaced its predecessor, HTTP/1.1, which stood firm since 1997, and since 2015 almost all browsers have support for this protocol. Their support also marked a significant jump in websites boasting announced, partial or full support of the protocol. To paraphrase Katy Perry: “you're gonna hear Google roar (through their SPDY protocol)”. Statistics of its usage can be found over at isthewebhttp2yet.com.

Finally, there are protocols that were positioned to make it big, but that never delivered on their promise. The WebDAV extension on HTTP comes to mind. It would take over from FTP, but never seemed to find proper advocates to raise public (technical) awareness. Although some communication servers support it (such as Apache HTTP and Microsoft IIS), and there is ample client support, it is just not used that much as a solution to any business or operational need. Unknown means unloved in the tech world, and most of the tech consultants I work with at my current project seem oblivious about its existence.

With all of these different “dead” protocols, we need to take a stance on how to cope with them in an enterprise. If they are used, what to do with them? The promise of SOA about technology heterogeneity tells us that these protocols can be shielded from the users and that the transformation from one protocol to another will be handled by an ESB or similar design pattern. This could lead it to think it is OK to leave these antiquated protocols in the technology portfolio, but at that time the technical debt will start to rise. As with any legacy, any roadmap should give serious consideration on how and when to phase out these relics of the past.

As with any migration to newer technologies, the numbers to be run are the cost of maintenance versus its upgrade cost. An archaic protocol may not be inherently broken, but its use to solve your business needs may well be broken in light of newer, faster, and more powerful alternatives. In any case, there are inherent benefits to the upgrade of any legacy to their newer counterparts:

  • Faster processing
  • Higher throughput
  • Lower maintenance costs
  • Faster deployment cycles
  • Smaller physical footprint
  • Lower operational costs

Thought SOA Infrastructure