About 18 months after finishing the MHP 1.0 specification, DVB released MHP 1.1. This is a fairly major move on from MHP 1.0, and it adds a lot of new elements to the MHP specification. We won’t cover them all here (expect updates on the major new developments in separate sections), but we will try to give you an overview of them.
Since the release of MHP 1.1.0, MHP has released MHP 1.1.1 (which integrated fixes from MHP 1.0.2 and 1.0.3) and 1.1.2 (which changes the smart card API and adds a number of enhancements to exisitng APIs). MHP 1.1.x is still regarded as a blank slate, and so it is this version of the MHP specification that is likely to see any major changes that break compatibility with previous versions. Since no-one has actually deployed MHP 1.1 yet, this is not a big problem.
Is bigger better?
Probably the most immediate thing that you’ll notice about the MHP 1.1 specification is that it’s a lot thicker. It’s grown about an extra 500 pages, and and it’s not as if it was a particularly slim specification in the first place.
One of the consequences of this is that most implementers (and so most developers as well) are avoiding MHP 1.1 for now. There’s still a lot to digest in the first version of the spec, so adding more complexity is not what most people want to do right now. At the moment, everyone is concentrating on getting MHP 1.0 receivers into the market and making that successful before moving on to the more complex stuff.
A second problem is that there is no test suite available for MHP 1.1 rat the time of writing. Without a test suite, there is no way to prove that an implementation meets the MHP 1.1.x specification, and guaranteeing interoperability becomes even harder than it is for MHP 1.0.2. For this reason, no-one is currently deploying MHP 1.1.x receivers. Having said that, some elements of MHP 1.1.x are required by some national regulators even when MHP 1.1.x is notformally in use. In particular, the Italian association of DTV operators (the DGTVi) requires all boxes in deployed in Italy to support the smart card API from MHP 1.1.2.
DVB-HTML
One of the biggest additions to MHP 1.1 is support for DVB-HTML (finally). An MHP 1.1 platform can support applications written in DVB-HTML, which will make certain types of application much simpler to develop. In particular, fairly static information services will be much simpler. DVB-HTML is a combination of the latest WWW standards, so you get a selection of XHTML 1.1 modules, CSS 2, DOM 2 and ECMAScript for your money (as well as some other features).
Of course, there’s a downside to this, and the size and maturity of DVB-HTML are likely to be its biggest problems. Many of these standards are not well-implemented in desktop browsers (take a look at the standards support in the big three PC browsers), and there are no standardized test suits for all of the DVB-HTML fuctionality, and so it’s difficult to prove that a browser meets the DVB-HTML specification. Add to this the problems of making sure that all implementations work the same (due to ambiguities in the specification or deliberate ), and life starts to get difficult, as web developers will already know. When you consider that DVB has stated explicitly that an MHP platform must support all the rest of MHP 1.1 as well as DVB-HTML, things are looking sticky, at least in the short term.
I’ll repeat that last point, because it’s easy to overlook: if you want to support DVB-HTML, your MHP implementation must support all of MHP 1.1.
DVB-HTML does have a lot of potential, but it remains to be seen how much it will actually get used. If you’re interested in learning more, a separate tutorial on DVB-HTML is available.
Inner applications
A feature that is stronly linked with DVB-HTML is support for inner applications. An inner application is one that is embedded within another MHP application, for instance as a component within the parent application or as an applet within a page in a DVB-HTML application.
The packages org.dvb.application.inner (for embedding DVB-J applications within other DVB-J applications) and org.dvb.dom.inner (for embedding DVB-HTML applications within DVB-J applications) both have a similar structure. Each package contains a container class for the application, which acts as an AWT object in which the application gets screen real-estate and which provides a way for interacting with the application, and an inner application class which encapsulates all the information about the inner application that the system needs.
The lifecycle of an inner application is fairly simple, since it is controlled by its parent application rather than by any application signalling information in the AIT. Creating an instance of an inner application container will initialise and start the associated application, while destroying the application container will also destroy the application. Inner applications are obviously tied to their parent application, and so when the parent application terminates, any inner applications will also be killed.
The Internet Access profile
The second big change in MHP 1.1 is the addition of a new profile. The Internet Access profile adds support for a web browser, email client and other Internet technologies. While most applications that implement this may also implement DVB-HTML, they don’t have to because they are actually different things. For instance, the Internet Access profile doesn’t specify what version of HTML the browser has to support, so the browser can support something simpler than DVB-HTML.
One of the most interesting things about the internet access API is the way that the internet clients coexist with the MHP applications themselves. Since there may not be enough resources in the receiver to run both the browser and the MHP application simultaneously, the internet access API uses the service selection API to determine how the lifecycle of the MHP apps is affected. Although at first this sounds rather strange, it does actually solve the problems associated with this in a neat way (I’m allowed to say that because even though I was one of the API designers, that particular part of it wasn’t my idea). This will be explained in more detail in a future update, so look out for that in the near future.
New APIs
MHP 1.1 adds a couple of new APIs for applications. While these are unlikely to be a compelling reason for moving to MHP 1.1. when compared to the other new features, it’s worth describing them for completeness.
The smartcard API for accessing non-CA smartcards has gone through two very different versions. MHP 1.1 and 1.1.1 used the embedded version of the OpenCard Framework for access to non-CA smart cards. This API is generally regarded as a ‘dead’ API, however, and so MHP 1.1.2 uses the low-level smart card API from the Java Security and Trust Services API (SATSA, also known as JSR 177). This allows applications to send and receive ADPU (Application Protocol Data Unit) messages to and from a smart card.
Neither of these smart card APIs provides access to smart cards used by the conditional access system – CA vendors are paranoid about allowing this kind of access, and so it’s unlikely that this will ever be supported by MHP. MHP 1.1.2 also adds limited support for the JAXP XML Parsing API and for APIs related to cryptography and security.
Plugins
Amongst the other problems of deploying MHP is the issue of what to do with all your old content. While replacing it may be the most elegant solution, this is an expensive option and is not always the best. The MHP plugin API allows you to re-use content by downloading a plugin for in in the same way that you’d download and register a plugin for a content format in your web browser.
In this case, the plugin is an MHP application designed to handle that specific content type. While plugins can be platform-dependent (i.e., tied to a specific MHP implementation), we won’t consider those here.
Plugins can also stay resident in the STB, to avoid re-loading it every time. This feature is dependent on the STB, and so not every STB will support it.
The topic of plugins is more complex than can be described in a short section like this, so expect a longer tutorial on plugins some time in the not-too-distant future. For those of you who are too impatient (or just know what our update schedule is like), some of the main highlights of plugin support are given below.
Plugin descriptors
Like any other application, a plugin is signalled in the AIT, but there are some differences from conventional application signalling. The application is signalled using a delegated application descriptor. This associates an application with a specific plugin.
The other descriptor that we care about is the plugin descriptor. A plugin descriptor gets added to each AIT entry that signals an application that will be used as a plugin. This identifies two things: which application types the plugin can support, and which profile and version numbers of the application type it can support. This allows the receiver to match an application that needs a plugin to the available plugins.
The Plugin API
Each application that will be used as a plugin (i.e. which is signalled using the plugin descriptor) must support the MHP plugin API. This is contained in the org.dvb.application.plugins package. The most important class from our perspective is the Plugin interface, which must be implemented by the plugin so that applications running in the plugin can be controlled by the MHP middleware.
Stored Applications
In a change from MHP 1.0, MHP 1.1. provides a way for broadcasters to tell a receiver to store certain applications. This may be useful with an EPG or news ticker application, for instance, where the time taken to load it every time would be annoying to a user. These applications may either be related to the broadcast, in which case the application is cached but it’s lifecycle is still controlled by the broadcast AIT, or it may be completely standalone, in which case the AIT entry for the application is stored along with the application files.
Broadcasters can signal an extra descriptor in the AIT, the application storage descriptor, which provides some extra information needed to control the storage of the application. This includes whether the application is broadcast-related or standalone, and also includes a version number so that stored applications can be updated if a new version is transmitted.
To store an application, it’s necessary to know which files to store. There’s no easy way of knowing this from looking at the application itself, so each stored application must have an associated application description file. This serves the same purpose as the application boundary in DVB-HTML applications: to identify what files are part of the application and which are not.
In this case, the application description file is an XML file that is contained in the base directory of the application it describes. The application description file must have a name in the following format:
dvb.storage.oooooooo.aaaa
where oooooooo is the organisation ID of the application, in hexadecimal format (padded to eight characters by leading zeroes, if necessary) and aaaa is the application ID, also in hexadecimal format and padded with leading zeroes if necessary.
The DTD for the application description file is provided in the MHP specification, and so I won’t cover it here in too much detail.
The evolution of MHP 1.1
MHP 1.0.x has remained a relatively static specification, apart from bug-fixing activities. While a large number of bugs were fixed in MHP 1.0.2 and MHP 1.1.3, these did not affect the basic APIs in any major way. The same cannot be said of MHP 1.1.x.
The baseline MHP 1.1 specification had a number of bugs, and since most of the effort has been focussed on MHP 1.0.x these bugs have often not been addressed. When you add the complexitry of the new MHP 1.1 features, there is a lot of untested and highly complex elements that are new in MHP 1.1. The MHP committee tried to fix some of the worst of these bugs in MHP 1.1.1, by integrating bugfixes from MHP 1.0.2 and 1.0.3. Unfortunately, none of the new MHP 1.1 features were addressed.
MHP 1.1.2 is an attempt to fix some of these, but it goes much further than that. MHP 1.1.x is still not deployed anywhere, and so it’s generally regarded as a blank slate when it comes to making changes. This is very evident in MHP 1.1.2, where the original MHP 1.1. smart card API is completely replaced, and several new APIs are added. While this breask backwards compatibility with previous versions of MHP 1.1.x, this is not a problem when there are no deployments to be backwards compatible with.
These changes are likely to be even more far-reaching in time. There is a good chance that DVB-HTML will be replaced with a new HTML platform that is compatible with that defined in the ACAP specificaiton. Much more thought has gone in to ACAP’s HTML support than went in to MHP’s (because HTML is a more important part of the DTV picture in the USA), and so it makes sense to harmonize around the platform that has been most thoroughly discussed. Again, this is not a big problem since DVB-HTML has not yet been deployed int he real world.
The lack of a test suite for MHP 1.1.x means that there is not yet any truly ‘official’ version of the standard (despite three versions being published), which makes these kinds of changes more likely and also contributes to the lack of interest in deploying MHP 1.1.x. Until a test suite is available and the ambiguities in the specification have been ironed out, expect these kinds of changes to continue in MHP 1.1.x.
Further reading
White paper from the BBC on MHP 1.1