4.5 Network Independent Resource Access

Content is likely to be delivered by multiple delivery systems. It is possible that, for a single interactive TV program, some of the resources are deliverable by means of multiple (possibly shared) broadcast channels (either terrestrial or cable) whereas other (custom) resources are deliverable by means of a return channel. Objects delivered by a certain method may refer to objects delivered by other means. Intuitively, it is expected that the collection of resources delivered define a virtual file system, which is similar to a traditional file system, with the exception that its components are partially in the sky (i.e., terrestrial broadcast), partially in cyberspace (i.e., a wide spectrum from walled-garden to the open Internet), and partially in the local receiver storage (e.g., RAM, disk, pluggable hardware). The delivery configuration, namely which resources are delivered by which means, may not be known at the time of authoring, or it may change dynamically over time. It is therefore required that receivers locate and retrieve resources from multiple networks on a best-effort basis.

To achieve true network independence, one can decouple the design and implementation of the application execution environment from the methods by which resources are delivered, receiver implementation may choose to introduce an asynchronous Late Binding Interface (LBI), which serves as a mediator between the application environment and the network; it abstracts out the details of resource access into a simple request-response mechanism (see Figure 4.13). The LBI implementation should actively listen on accessible broadband network channels and should construct, in an implementation dependent manner, a complete index of its content. On receipt of an object request, the LBI implementation provides one or more responses that unambiguously map to that request. The application environment may rely on the receipt of a response to every request, but the time period for the response is context sensitive and may vary greatly. Nevertheless, receivers should utilize their local cache to store the complete index as well as some resources, before a request to retrieve their data is made. Further, the LBI could be implemented to issue responses that a resource is being searched or is likely to be received soon but without delivering the requested content.

Figure 4.13. Using the Late Binding Interface (LBI) as a data delivery abstraction layer.

4.5.1 The LBI Request

Each request from the application environment to the LBI should contain a request ID that is unique among all requests not yet canceled or otherwise completed. At least three types of requests should be supported:

• Request object by name : This request specifies the name of an object. This name should be a URI referring to that object, preferably an absolute URI. The request may not specify the method by which this object is retrieved, therefore allowing the LBI to perform a best-effort to retrieve the object from all available connections.

• Request events by type : This request could be regarded as an event filter expecting one response per occurrence of the event type specified in the request. Two types of events should be supported:

  • Application life-cycle signaling event : These are events that would impact the life-cycle of an application. Support should be provided to events such as NewApplicationAvailable, LoadApplication, LaunchApplication, ApplicationNoLongerAvailable, TerminateApplication , and so on.

  • Synchronized presentation event : These events are triggers used to synchronize the presentation of some data, e.g., callout or selectable hot region, with the background video. These events carry a URI reference to an object to be presented when the trigger is activated. Whereas synchronized triggers contain their exact presentation time, asynchronous triggers contain no presentation time and should be activated as soon as they are received. In cases where the same trigger is transmitted repeatedly, only a single response should be issued.

• Cancel previous request : This is a request to cancel a previous request having the same request ID. A request should be regarded as open until it is explicitly canceled by a cancel request. The purpose of this is to enable the application environment to effectively control the number of open responses and notify the LBI when to stop the search or download of an object. This handles event filtering well, and in addition, it handles situations when resource are dynamically changing and a response needs to be sent to notify of a change. Further, application environments may introduce time-out logic, channel change logic, or any other logic that requires the cancellation of a request before a file is received.

4.5.2 The LBI Response

Each response should minimally contain the ID of the request it responds to. At least two types of responses should be supported:

• Successful Access : This response should minimally contain the retrieved resource. Optionally, it may specify which protocol was used to retrieve the resource.

• Exception : This response should be issued in all cases when the data is not available, or the data retrieved is suspected of being incorrect. If the request did not specify the retrieval method, then such a response should be generated for each protocol with which access has failed, providing a notification to the application environment with exactly which attempts failed. The challenge is to map the specific protocol exceptions to an LBI response; a trivial solution would pass the protocol information together with an exception as is.