MHP has APIs to do almost everything except make coffee for the developers, and that will probably get added in version 1.2. Interactive TV applications fall into a wide range of categories, needing different support from the middleware and placing different demands on the platform. The very nature of interactive TV, where cost pressures and highly specialized hardware play off against the demands for sophisticated applications that look good and perform well, means that applications need a set of APIs that are even more complex than those needed by many PC applications. In general, these APIs can be put into several categories:
- Low-level MPEG access
- Access to broadcast data
- Media control and playback
- Application lifecycle
- Graphics and user interface
- Communication with a back-end server or other applications
- Access to receiver hardware and peripherals such as smart cards
- Security
Not every application will use all of these APIs, but even simple applications will use a large number of them. Not only do the APIs have to be flexible enough to meet the needs of many different types of application, but they must also take account of the limitations imposed by the platform (both in terms of the underlying hardware and the lack of memory that comes with having to build your product to a budget). On top of this, they have to be reliable.
It’s important to realize that the MHP APIs are designed the way they are for a number of reasons (some of which we’ve just mentioned), and that one of the biggest of these reasons is paranoia. Any consumer electronics product has to be incredibly reliable, and this gets to be even more important when you are talking about complex CE products that can download and run applications written by one or more third-parties . There are three main reasons for this paranoia:
- Reliability. These applications have to work all the time, on every box. That’s tough to achieve without restricting what an application can do, and how it does it.
- Expectations. People are used to their PC crashing – they’re a lot less used to their TV crashing.
- People will probably not blame the content authors for any crashes. If you’ve got a Sony set-top box, it’s the Sony STB that’s crashed, not the application. This means that CE manufacturers are extra-cautious, because they will get the blame even if it’s not their fault.
This thinking affects a lot of the API design. In many cases, you’ll notice that API methods ‘suggest’ or ‘hint’ or ‘request’ that something happens. You’ll also notice that the APIs allow for a lot of different failure conditions that an application can handle. The whole purpose of this is to make applications (and the receiver itself) more reliable, by making sure that the system software on the receiver is always in overall control.
One of the implications for software developers is that they should take into account all these potential failure conditions that the receiver may report, and use these to build reliable applications. There’s a well-known software development saying: ‘never check for a failure condition that you don’t know how to handle’. In a digital TV application, developers should know how to handle all failure conditions.