So, you've finished reading all these tutorials, and you've taken a look at the specification, and you've decided that you like this MHP stuff. The only trouble is, you've got a big installed base of current receivers and broadcast equipment out there that don't support MHP. What can you do?
There are several approaches to this, depending on your current middleware and the limitations of your network. In general, migration scenarios fall into three broad categories:
The first of approach is simulcasting. In this case, all applications are transmitted in both MHP and non-MHP versions. This requires a more bandwidth, although we can limit this by designing our applications share data files. MHP applications can be designed to read data from proprietary stream formats using the MPEG section filtering API, and I have even seen this used to implement support for proprietary broadcast filesystems. When this is combined with MHP's support for various common iTV data formats and the way MHP builds on existing standards (especially at the lower levels), switching to MHP starts to look less like an insurmountable obstacle. This approach offers a lot of flexibility when it comes to sharing content and assets, but it does mean that the broadcaster must maintain and manage two sets of applications during the changeover period.
The second approach is to upgrade the existing receivers to support both MHP and their current middleware. Most of the major middleware vendors such as OpenTV, Canal+, and NDS offer MHP support for their middleware, usually as an additional module. Receivers can be upgraded with this new functionality using an over-the-air download, and so these receivers can run either MHP or non-MHP applications following the upgrade. The big disadvantage of this approach is the cost: MHP support may cost an additional $5 per receiver or even more, and so this is not a cost-effective solution for migrating all receivers to MHP. It may be cheaper than recalling all of the old receivers and replacing them, however, so there may be cases where this approach makes sense.
Of course, there is a lot more to moving to MHP than this. You have to have content developed, and that means finding content developers - either hiring your own or contracting to an external company. If you are a content development company then this obviously means hiring your own or retraining existing staff. What does MHP mean to content developers?
Since all MHP applications are written in either Java or HTML, there's a temptation to think that if you can write web applications then you can write MHP applications. This is simply not true. MHP is not the web. There are some major differences between the philosophy of web applications and the philosophy of MHP applications, not least the importance of cooperating nicely with other applications and with the receiver, the importance of bullet-proof reliability and the need to run on many different sets of hardware and software.
In many cases, existing digital TV developers who have a knowledge of Java are probably more suited to MHP development than web developers trying to get into digital TV. Why? Well, at the end of the day, Java and HTML are just languages. Learning them isn't that complex. Learning what happens when you build an object carousel that is not well-optimized, or learning why your application really should catch all exceptions, check all return values and handle all possible cases takes time - it's about experience and attitude and domain knowledge. I'm not going to claim that it's impossible to learn this quickly, but usually it takes time because there's no fixed set of guidelines that you can apply and so you have to learn from experience.