OCAP allows network operators to do more than just download applications to the receiver and then run them. Network operators can also choose to store certain applications in the receiver’s non-volatile memory, and make them available to the user without having to download them every time. The most obvious example of this is the monitor application – downloading a monitor application every time the receiver starts would be slow and cumbersome, and so the network operator typically stores the monitor application on the receiver when an updated version is available.
MHP 1.1 also supports stored applications, but in a very different way: in MHP, the ability to store applications is far less important in an average situation. OCAP exploits this ability much more. In addition to the monitor application, an OCAP system may store other applications that are provided by the network operator such as an EPG, a news ticker, a PPV client or other unbound applications.
Storing an application
Applications can be stored in several ways. The simplest of these is to include them when the receiver is manufactured, by including them in the firmware image that is initially installed on the receiver by the manufacturer. They can also be included when the receiver firmware is updated in the field. The OpenCable Common Download Specification describes the mechanism for this. Applications installed by the manufacturer will all have the same organisation ID, but as with other applications they must have an application ID that is unique within the context of that organisation ID.
Receiver manufacturers can choose to download a complete image or a partial image of the firmware. In the former case, any applications which have the manufacturers organisation ID will be deleted from the flash memory will be removed, and a complete new set of applications will be downloaded and stored. For a partial image, the image contains a list of those applications that are to be updated or removed. Any stored applications with matching application IDs will be removed before the new image is downloaded, but all other applications will be kept.
Storing applications from application signaling
The second most common way to store an application is via the XAIT signaling. Application descriptions in the XAIT can contain a field to indicate the storage priority. This allows the receiver some leeway in deciding which applications to store: since some receivers may have more free storage space than others, the receiver knows which applications are most important and can make sure that those are stored first.
This priority value can be in the range 11-255, with a higher priority value indicating that the application is more important. A priority value of 0 indicates that an application should never be stored.
As we have already seen, an XAIT doesn’t have to come via the signaling. An application with the right permissions can register a new XAIT using the AppManagerProxy.registerUnboundApp() method. In this case, the XAIT that is passed in handled in the same way as a broadcast XAIT.
If the receiver doesn’t have space to store a given application, then applications with a lower priority will be removed until enough space is available. If several applications have the same priority and there isn’t enough space to store all of them, the receiver itself can choose which application to store. This means that if it’s important that one application gets stored in a given situation, make sure it has a higher priority than other applications you want to store.
In some cases, the priority of an application may change. When this happens, the receiver should check to see whether the application is already stored. If it is, then its stored priority should be updated to reflect the new value. If it isn’t already stored, the receiver should check to see whether the new priority is higher than any currently-stored applications, and remove them to make space for it if its priority is higher.
When the broadcaster signals a new version of a stored application, the receiver might overwrite the old version of the application with the new one. Exactly when this happens may not be completely predictable – if the old version is running at the time, the receiver may choose to store both versions until the currently running copy stops. At that time, the old copy will be removed form storage. If the receiver chooses to delete the old copy before the application finishes, the behaviour of the application must stay the same – in practice this means that all classes must actually be loaded into memory before the old version is deleted.
Observant readers may have noticed that we said the new version of an application may overwrite the old one. This gives network operators a little more flexibility to decide how applications are upgraded. A network operator can broadcast two versions of an application simultaneously, with the old version being having a higher value for the launch order than the newer version, but having a lower (or identical) storage priority. This enables receivers to completely store the new version of the application before it’s removed by the network operator. This gives a better chance that the new application will start up quickly when the old version is finally removed, and lets the network operator provide a better user experience at the temporary expense of some storage capacity in the receiver. When the old version of the application is deleted, its storage can be reclaimed and used for storing other applications.
While this isn’t useful in every case, it can be extremely important for commonly-used applications. Using this approach to upgrade an EPG application lets the network operator ensure that the EPG will always start quickly when the user selects it, even if it’s being upgraded.
What’s in an application?
Obviously, if we’re going to store an application, we’d better have a pretty good idea of which files actually make up the application – it would be pretty embarrassing if we forgot to store half of the files we needed, after all. To do this, every application that is to be stored must have an associated application description file.
This file is an XML file that’s stored in the base directory of an application. This file will have a name that follows this pattern:
ocap.storage.xxxxxxxx.yyyy
where xxxxxxxx is the hexadecimal value of the organisation ID (padded to 8 characters using leading zeroes in cases where it’s shorter) and yyyy is the hex value of the application ID (zero-padded to 4 characters). The application description file contains the names of files or directories in the object carousel, and sizes for each of them. Any files or directories listed in this description file (which can contain the ‘*‘ wildcard must be stored. If for some reason, a file can’t be stored (for instance, because there’s not enough storage) then that application must not be launched.
Application developers should take care to include an application description file for every application that will be stored – if this file is missing, the receiver must assume that it has to store the entire carousel on which the application is broadcast!
Stored apps and the application database
Stored applications will appear in the application database, just like any other application. In addition to the applications files, the receiver will also store some information about that application from the XAIT. Exactly how this information is stored depends on the manufacturer – it may be an XAIT fragment, or it may be something different. The receiver must store any information that was available to it when the application was stored (or the latest version of the information if the associated XAIT was updated after the application was stored).
When the receiver starts, this information is loaded into the application database before the monitor application starts. This enables the monitor application to have access to all available information about stored applications, just like the information that it has for downloaded applications.
Running a stored application
Once the monitor application starts, it treats stored applications just like any other application. Their availability is indicated by the control code that’s included in their XAIT signaling. Applications that are signaled as auto-start will be started when the monitor application loads (resources permitting). Any applications that are signaled as available will be displayed to the user in the same way as any downloaded applications that are available. Really, there is nothing special about stored application in OCAP from a lifecycle perspective – their only purpose is to let some applications start quicker than others.
Just like other applications, stored apps must be authenticated before they can be run. In the case where an application fails this authentication process, a new version of the application must be downloaded before it can be run. Once an application has been authenticated, however, it will continue running and will not be authenticated again until it restarts. This means that if the certificate associated with an application expires while it is running, the application will continue to run normally.
Removing stored applications
As we’ve already seen, applications can be removed from permanent storage when their priority is too low and other applications need to be stored in their place. They will also be removed when their priority is set to 0, or when no priority value is given for them in the XAIT. If an application has registered stored applications via the AppManagerProxy.registerUnboundApp() method, then the same application can call the AppManagerProxy.unregisterUnboundApp()to remove that application from storage. This is a less common approach, however.
Applications can also be removed from local storage in one other circumstance – when the receiver chooses to.
Yes, this is a bit vague. However, this vagueness means that the receiver can handle special conditions as they arise. It does mean that developers and network operators have to be careful, however: just because you signal that an application should be stored,and just because that application should be stored according to the rules of the specification, things may go wrong. Sometimes, that application may not be stored.
Moving between networks
When a receiver moves from one network to another, any stored applications will be removed. The receiver checks the organisation ID of the current (stored) monitor application against the copy of the monitor application that is being broadcast. In this case, the receiver will remove any stored applications where the organisation ID is different from the that of the receiver manufacturer or the that of the broadcast monitor application. This lets the receiver ensure that no old applications are carried across to a new network, and that as much storage space is possible is available for stored applications from the new network.