When you first look at MHP, some elements of the design may appear inconsistent or questionable at first. While this isn’t entirely surprising in a specification that is as big as MHP, there are often good reasons why things worked out the way that they have.
In this section, we will give some background on why MHP is the way it is, the rationale behind some of the design decisions that got made by those of us who were developing the spec and the general philosophy of MHP. It’s probably going to be shorter than some of the other tutorials on this site, but that isn’t necessarily a bad thing. Similarly, this is not a technical guide to any piece of MHP – this is about the politics and the history. Having said that, it will hopefully give you an insight into some of the technical parts of the specification.
Some history (or, MHP in relation to other standards)
The first thing to notice about MHP is that it’s not just one standard. It’s actually built on top of a large pile of other standards. Some of these are from well-known standards bodies such as ISO/IEC and DVB itself, others are from industry groups such as HAVi and DAVIC and yet more are from individual companies who are promoting specific technologies (e.g. Sun Microsystems with JavaTV). In order to understand this a bit better, it’s necessary to look at some of the history of MHP.
Many people who worked on MHP had also worked on other interactive TV standards in the past. The first of the open standards for interactive TV was a declarative, object-based technology called MHEG. Several versions of MHEG were developed, with MHEG-5 being the most successful of these. MHEG-5 was originally deployed on the now-defunct OnDigital service i the UK, and is still used by the services that replaced OnDigital (first ITV Digital, and now Freeview).
After a while, more interactivity was needed and the support for external scripting languages was added to MHEG. The MHEG-6 standard added support for using Java as a scripting language, as well as a Java API for accessing MHEG-6 objects. DAVIC (the Digital Audio-Visual Council) took the MHEG-6 standard as the basis for a new interactive TV standard. This was a little more Java-centric, and added more Java APIs to perform more features. This included adding support for the Java Media Framework to control media playback, and adding APIs for describing basic MPEG concepts, section filtering, controlling tuning and for resource management. Both of these standards were agnostic about the underlying technology, and said very little about how an application was delivered. Instead, they focused on the interoperability aspects and on using Java to support features that were not possible using MHEG. For those people who are interested, the later
DAVIC specifications can be downloaded from their web site. The specification is split into several parts, with part 9 (Information Representation) being the one of most interest to MHP developers, since this includes the specification of the various Java APIs.
MHEG-6 was generally not a success, either in its standalone form or as part of DAVIC, and by the time that DVB started developing an interactive TV standard there was fewer perceived problems with using Java as the basis of a digital TV platform. Many of the people working on the MHP standard were involved in previous standardization activities all the way back to MHEG, and so it’s not surprising that many of the Java APIs from DAVIC and other standards were re-used. These were still considered to be appropriate for the task, and it was generally easier to modify the existing APIs to meet the needs of MHP than to define a whole new set of APIs.
Design by Committee
As with many standards, MHP is a group effort. Potentially worse, it’s a group effort that incorporates parts from previous group efforts. Many software developers and designers of any type can tell you that design by committee is usually a Bad Thing. Some will argue that it’s a Bad Thing in the case of MHP – I’ll leave this up to your own judgment and your own biases.
However, there are a few things that we can say about this process. Different parts of the MHP specification were developed by different people (or groups of people), and those groups had different levels of understanding about other aspects of the system and how they were supposed to work. To pick an example, the DAVIC resource notification API is used in many places with in the DAVIC and MHP APIs. However, it’s applied in an inconsistent manner, and so every API that uses it ends up using it in a slightly (or sometimes very) different way. Part of the reason for this is that some people didn’t understand the rationale behind the design. It’s also partly that people tended to focus on specific APIs and so very few people had a deep understanding of the whole API set. Luckily, some of the people who have this understanding can sometimes be found answering questions at the MHP forum on the official MHP website.
For a good illustration of the problems that this approach faces, I’ll describe a situation that happened during one of the later standardisation meetings. By this point, most of the JMF extensions, JavaTV service selection API and basic Xlet lifecycle were all mostly standardised and the basic principles of the APIs were stable – all that was left was the arguing over the details. As part of a team writing an MHP implementation, I had implemented these APIs and got them to mostly work together. However, I wasn’t completely sure that I was taking the right approach, and so during a break in one of the meetings I spoke to a number of the other people involved in standardising these APIs. No-one could answer my questions, and everyone had a different idea of how they should work together. So much effort had been put into standardising the APIs that no-one had the time to sit down and work out in detail what happened when you put them all together. The result of this was Annex Z of the MHP 1.0.1 specification,
which started out as a white paper describing how things worked in that particular implementation and which has since become the recommended practice for all MHP implementations.
To give another example, as part of the preparation of the test suite an external consultancy was brought in to look at the standard and design some test cases. Many, many specification bugs, ambiguities and inconsistencies were found in this process, just because someone who hadn’t seen the spec before sat down and read the whole thing in detail. It’s easy to make assumptions about the behaviour of some parts of the system, and it’s hard to make sure that all those assumptions get written down so that everyone can share them.
What’s the moral of these stories? Mainly, that while many of the rough edges and inconsistencies have been fixed in later versions of MHP, some problems remain. Given that it’s over a thousand pages of technical documentation, that refers to many thousands of other pages of technical documentation, it’s not completely surprising that there are some places that could be improved. Some of these are being worked out through the corrigenda (bug-fixing the standard) process that’s ongoing, and some of them may be fixed in future versions of the standard.
API re-use and subsetting
As we’ve seen, MHP has its roots in a number of other standards, and many of these standards are visible in the APIs – for instance, the org.davic.*, org.havi.*, and javax.tv.* packages, as well as less obvious influences. Part of the reason for this is the need to be interoperable with existing standards, but part of it is the desire to avoid re-inventing the wheel. Re-inventing the wheel is sometimes necessary, but only if you know that the current solution has problems. These could be demonstrated problems from trying to use that solution, or it could be that the requirements have changed and so external APIs haven’t been adopted willy-nilly: third-party APIs were only adopted if they actually seemed to fit the need reasonably well. Some minor changes are OK, but if major changes are needed, then a different API would be developed.
The consumer market is a fairly small arena, and the DTV market is even smaller. In each of these areas, it’s not surprising that other bodies had already defined standards (even if those standards weren’t very successful commercially). For instance, the HAVi standard included the ability for devices to control each other, displaying the UI on the most suitable device. For this, they needed a Java-based UI solution that could be used in a consumer environment, and which would work on a TV display. Given that MHP also needed a Java-based UI for a consumer display, it made sense to use an existing one that met most of their requirements. The same thing happened with DAVIC for low-level APIs for MPEG concepts and resource management.
Typically, MHP will not take a subset of an API and will either take the whole API or none of it. This isn’t always the case – for instance, elements of the Java APIs are left out, and only some packages from other APIs are used. It’s rare for any subsetting to happen below the package level, however, and when it does, it’s usually for space reasons. For instance, many of the locales from Java aren’t required on an MHP platform simply because of the space they take up in ROM. In other cases, entire APIs may be retained when the potential problem of removing them is higher than the cost of leaving the API in place. This was especially true in the JavaTV API, where there was another benefit to leaving the API in place for compatibility reasons as we’ll see later.
Instead of subsetting an API, restrictions (or additional requirements) will get imposed that limit those areas that need to be changed. For instance, the MHP specification requires that a JMF player supports a number of controls that aren’t required by the original JMF specification. Similarly, limitations are imposed on the java.lang.System class and others in the core APIs. These are usually not phrased as "X will not be present," but are instead phrased as "interoperable applications will not use X." In this case, X can be present but it may only be used by the middleware (java.lang.System.exit(), for instance, should not be used by MHP applications, even though it will probably be in the implementation). In this case, it’s easier to forbid applications from calling it than it is to remove the offending method(s) or class(es) from the API.
One tool for every job
MHP’s philosophy is very much "one tool for every job". This does conflict sometimes with the philosophy of re-use described above, and there are a few places where you will see a couple of ways of doing the same thing. The JavaTV and DVB service information APIs are one place where we can see this, as are the graphics blending features of the DVB and HAVi user interface APIs. In both of these cases, though, there are differences as well. The functionality doesn’t overlap completely, although there may be cases where a developer can use either of the two approaches with no major side-effects.
Usually this overlap occurs when a third-party API is included as part of the MHP specification and where it doesn’t quite meet the needs of MHP or is included to be compliant with another specification as well. Removing the JavaTV service information API would have avoided this overlap, but other JavaTV packages use classes from these APIs. Solving these dependencies would have caused more work for MHP and moved it further away from the original JavaTV APIs. It would also have made harmonization much more difficult: JavaTV is a common API that is not tied to a specific set of DTV standards, and so leaving the JavaTV SI API in place makes it easier for application developers to build MHP applications that also work on OCAP or ARIB platforms. Since MHP was designed (at least in part) to provide a common middleware platform, this is an important feature and it was felt that the overlap was worth the benefits that it gave.
Hopefully, this will have given you some insight into why some of MHP’s more inconsistent-looking features are the way they are, and why MHP refers to so many external specifications. Unlike a formal standards body such as ISO/IEC, it’s a little easier to work around some problems in a more informal industry forum like DVB. There are still issues, of course – for copyright reasons, the MHP specification can only refer to some other documents, and you will notice that the spec is very careful to note which version it’s referring to. These issues, and many others, all affect the final specification, and while it may cause problems for middleware implementers they are all necessary evils that we must pay attention to.