Write once, run anywhere: a lesson for digital TV
The end result is we have a wide range of software specifications, development environments and technologies. Notice that so far we haven't even touched on the prickly subject of hardware. Thanks to the continuing pace of innovation, hardware now stretches beyond the traditional STBs to include mobile phones and PCs among other systems, with a wide range of chip sets.
Even with a language that promotes the ability to write once and run anywhere, such as Java, we are still left with a plethora of confusing acronyms and development frameworks. This reminds me of the old enterprise development world where each platform, each language and each vendor had their own competing standards.
Integration between one environment and another was unheard of, except via bespoke - and expensive - development projects. Even those attempts at create integrated environments that did succeed were expensive, clumsy and generally hard work.
Looking at all of these one can't help but wonder whether the digital TV and STB world, especially given the format wars, isn't making the same mistakes as the enterprise made a decade ago.
Surely we can learn from what has been done there. For example, could we not have a set of language-independent standards that define a set of services that a digital broadcaster works to? Using these services different implementation languages could plug into these services via a language-independent interface.
Of course, the GUI on the STB or PC or whatever device is running the client side of the broadcast would be implemented in the favored language - that could be Java or whatever - but that would then be independent of the broadcast side of things.
This would immediately remove many of the barriers to entry, the maintenance costs and the incompatibility issues that are the subject of huge amounts investment by the industry intended to overcome these issues.
All of this brings me back to "simplicity". Recently, I have argued that simplicity in software should be paramount and I think that within the DTB field this is no less true. Lessons should be, and can be learned, from the older - and arguably more mature - enterprise world.
These can be both from an architectural point of view - such as a DTB version of SOA - through platform- and language-independent transport mechanisms - the STB equivalent of SOAP/HTTP - through to the APIs themselves.
It won't be easy, as Java itself has shown with Java 2 Micro Edition (J2ME) and its many sub specifications for different types of resource limited devices. However, it is a goal worth pursuing.®
Sponsored: Customer Identity and Access Management