HNTF/Home Network TF Discussions/LocalLink

From Web and TV IG

Use Case: Local Link of Web Applications

Submitter(s): Sony (Tatsuya Igarashi)

Tracker Issue ID: ISSUE-24

Description:

  • This use case is about the bi-directional communication between web applications via the local IP network e.g. Home IP network
  • Assumption
    • User devices are connected to the same local IP network
    • The applications (including Web Widget) on user devices know each other and can exchange messages for communications << Comment: You can use just the word "application" since our definition includes also widgets - Giuseppe Pascale 12:41, 14 June 2011 (UTC)
    • Note that the applications may not necessarily be provided by the same distributor or service provider (added --Tatsuya Igarashi 11:55, 14 June 2011 (UTC))
    • A user uses the IR remote controller to operate the HTML5 browser on the TV device (10 feet UI)
    • A user uses the touch screen to operate the HTML5 browser on the tablet device or smart phone (Touch UI)
    • Note that the application may not necessarily to be an web application as long as it communicates by the same network protocols as the user-argent does. (added --Tatsuya Igarashi 11:55, 14 June 2011 (UTC))
  • User Scenario A - Single User
    • Bob operates the TV device to watch movies on an online video service
    • Bob also operates the tablet device to access a social network service about movies
    • Bob views web pages of the social network service and find a favorite movie
    • Bob clicks the “your device” button on the web page of the social network service
    • The application on the TV device show the web page of the video service about the movie, then Bob starts to watch the movie
  • User Scenario B - Multiple Users
    • Bob operates his smart phone to use an application for a picture service
    • Alice operates her smart phone to access another picture application
    • Bob selects his favorite picture and clicks the “Sharing photo with other device” on the application
    • The application on Bob’s device shows the device name list and he selects the Alice’s device
    • The picture file is transferred from the Bob’s device to the Alice’s device while each application shows the progress bar of file transfer
    • After the transfer is completed, the application on the Alice’s device shows the Bob’s favorite picture
  • User Scenario: Interactive quiz (proposed by Matt Hammond --Tatsuya Igarashi 06:50, 23 June 2011 (UTC))
    • Alice and Bob operates the TV device to watch a quiz programme, from live broadcast
    • Alice and Bob also operate their smart phones to access a quiz application
    • Note: The smart phone quiz application knows that the quiz programme is being watched on the TV and establishes communication with an interactive application on the TV that is active during the quiz programme)
    • The TV application overlays on-screen information informing Alice and Bob that they are now taking part in the quiz.
    • As a question is asked in the quiz programme, the interactive TV application instructs Alice and Bob's smart phone quiz applications to ask Alice and Bob the same questions. Alice and Bob enter answers to the questions using their smart phones, which are relayed back to the interactive TV application.
    • Between quiz rounds, Alice and Bob's scores are displayed on their smart phones and overlayed on screen by the TV interactive application. Scores are compared to those of the contestants featuring in the programme.
    • Note: Regarding need/justification: Using local-link communication to an interactive application provided as part of a broadcast stream provides a way around scalability concerns if participation is substantial for a particularly popular programme.
  • Use case (System Interactions)
    • An User-Agent discover other Users agent on the same IP-sub network
    • Via API, the User-Agent provides the discovered application list which contains the applications which are running on other user-agent, e.g. application id, the URL for message exchange, physical device name(for user selection) (Comment: In this use case, only the applcation specified by application id should be discovered via the API because of the privacy concern --Tatsuya Igarashi 11:55, 14 June 2011 (UTC)
    • The application establishes the bi-directional communication for message exchanges with the application on the other user-agent via API
  • Implementation Examples
    • For the local discovery, the HTML5 browser implements UPnP Discovery to provide the generic discovery API to find applications on the same IP sub-network
    • For the message exchange, the HTML5 browser implements the extended WebSocket protocol and APIs for bi-directional communications
    • The HTML5 browser should implement some mechanism to confirm the user consensus to permit the device discovery and message exchanges for the applications

Need/justification:

  • The “Local Link” enables applications to exchange message, e.g. String, Blob, via the local network directly. Without the “local Link”, the applications which are running on different devices can in-directly communicate via a service on the Internet. But, the “Local Link” has the following benefits
    • Adhoc: Without any syndication of services, the applications provided by different services can communicate each others in ad-hoc. Also, all devices are not required to be bound to the same service. This is a kind of service mash-up using multiple devices
    • Efficient: A large size of files can be transfered between devices via high bandwidth local network connection.
    • Off-line: Even if the Internet access is not available, the applications can still communicate
    • Use-centric: Users can easily recognize which devices communicate. Only devices on the same network are listed and the communications of different user device are based on the user consent
  • There are some standards of local discovery, e.g. UPnP, Bonjour, WS-Discovery, but there is no standard of the JavaScript API which enables communications between Web applications in the manner of application/service agnostic

What needs to be standardized: --Tatsuya Igarashi 04:18, 20 July 2011 (UTC)

  • Type of use case: Generic APIs
    • General service discovery and messaging APIs should be standardized
    • Network protocols for the APIs should be specified

Dependencies:

  • Any other use cases related to the local IP network discovery since the discovery is also application/service agnostic

Comments:

  • The above user scenarios s are examples. As long as the message exchange API is service/application agnostic, many rich user experience can be realized as the open web platform does
Retrieved from "https://www.w3.org/2011/webtv/wiki/index.php?title=HNTF/Home_Network_TF_Discussions/LocalLink&oldid=666"