Submitter: Jean-Claude Dufourd, Telecom ParisTech
Tracker Issue ID: ISSUE-6
Description: A document as provider of a service: rendering a document on my HbbTV set provides an EPG service on the network, that other documents rendered on other devices (e.g. tablet) can discover and communicate with to get the EPG information. Another way of looking at this use case is: two documents discovering and communicating with each other.
Implementation: Possible implementation on top of UPnP:
- the document A is an HbbTV broadcast-related application, which is allowed to call the function returning the description of the next program.
- the document A exposes a service with one message getNextProgramDescription using SSDP.
- a document B on another device discovers the service (not knowing that it is a document, it is just another UPnP service to doc. B).
- document B binds to the service
- document B sends a getNextProgramDescription message
- document A receives the getNextProgramDescription message, calls the HbbTV function returning the description of the next program, replies to document B.
Neither document A or B know the actual nature of the other. They may have an IP address, and they share a service type.
Justification: Allowing to share resources other than content, such as a capability (a large screen, a sensor) or an "authorization" (permission to use a restricted API).
Comments: This UC asks the questions: how does a document expose a service, its interface and respond to requests on this service ?
Bob Lund disagrees with the generalization: "The term "document" is being used in a manner synonymous with a web page. I think a general mechanism to allow web pages to discover and communicate with one another is out of scope."