Home Network discovery

This document is an attempt to explore how Home Network services could be exposed to a web application using different approaches. For a detailed list of UCs that the Home Network TF has discussed take a look at the HNTF requirement document

For each option pro and cons are listed. None of the options at this stage are endorsed or recommended.

References

List of useful links:

Use case: browse and play

Browse content stored on your DVR and play it from your PC.

Steps:

the user browse to "the ultimate home player" web page
the page ask the user to pick some content to playback
the user browse the content from the DVR in his home network
the user select a video.
the page playback the video stored on the DVR

Opt 1

Use the pick intent.

Registration

The UA will discover HN services able to expose content on the home network and list them to the user when the intent is started. How discovery happens is implementation specific.

Invocation

var intent = new Intent("http://webintents.org/pick", "video/*");
window.navigator.startActivity(intent, function(intentData) {
  var selectedVideo = document.getElementById("video");
  video.src = intentData.data;
});

Comments

Pros:

easy to use for app developers
protocol agnostic (hn protocols are handled by the UA and hidden to the application)

Cons:

only network protocols supported by the UA can be used (e.g. if the UA do not support UPnP, no way to communicate with a UPnP device)
support of newer version of the protocol require UA update

notes:

the picker application may be a integrated into the UA or be a web application running on the device (i.e. the DVR).

Opt 2

Use the discover intent.

TBD

Use case: push play

Find the video from your table/pc/mobile then render it on the TV and watch it there

Steps:

the user browse to a page that contains a <video>
the page ask to play the <video> on a HN device
the UA shows to the user a list of devices able to do Playback (TV-living-room, TV-kitchen)
The user selects TV-kitchen
The video is rendered on TV-kitchen.
The user controls the video playback from the PC/tablet/phone

Opt 1

Use the view intent.

Registration

The UA will discover HN services able to render video content and list them to the user when the intent is started. How discovery happens is implementation specific.
The UA is also responsible for translating messages coming from/going to the application into the appropriate format for the supported protocols (e.g. UPnP)

Invocation

alt a) Use a URL

var intent = new Intent("http://webintents.org/view", "video/*","http://example.com/video");
window.navigator.startActivity(intent,function(intentData){
  //communicate with the HN device using an high level protocol (based on JSON?)
  //e.g. get error notifications, be informed when the video stop playing
   intendData.channel.port1.postMessage = ...e.g JSON according to some TBD "view" protocol
   intendData.channel.port1.onmessage = ....e.g JSON according to some TBD "view" protocol
 
});

alt b) Use Activity streams video object?

Comments

Pros:

easy to use for app developers (no difference between playback on local client vs other device)
protocol agnostic (hn protocols are handled by the UA and hidden to the application)
no information about devices/protocol exposed to the application

Cons:

only network protocols supported by the UA can be used (e.g. if the UA do not support UPnP, no way to communicate with a UPnP device)
support of newer version of the protocol require UA update

Opt 2

Use the discover intent and use type to specify the network protocol

Registration

The UA will discover HN services able to render video content and list them to the user when the intent is started. How discovery happens is implementation specific.

Invocation

Example: UPnP AV Transport service

var intent = new Intent("http://webintents.org/discover", "urn:upnp-org:serviceId:AVTransport");
window.navigator.startActivity(intent,function(intentData){
 //communicate with the HN device using UPnP
});

Example: XBMC JSON/RPC

var intent = new Intent("http://webintents.org/discover", "_xbmc-jsonrpc._tcp");
window.navigator.startActivity(intent,function(intentData){
 //communicate with the HN device using jsonrpc
});

Comments

Pros:

The UA is not required to support any specific protocol for communication (discovery still needs to be supported by the UA)
Updates in the communication protocol can be handled by the application without needs to update the browser

Cons:

More complex for application developers if the communication protocol is complex (e.g. UPnP)

Opt 3

Use the discover intent and use type to specify a high level network independent protocol. The TV Service is dynamically created through local service discovery, e.g. UPnP SSDP discovery. In this use case the Service has no UI, i.e. once the Service has been selected by the user in the Web Intents picker dialogue, the UA continues to show the Client page, in which the video playback control buttons reside.

Registration

The user could manually register static Services able to render video content by visting web pages. For local dynamic Services a local discovery process such as UPnP SSDP is used. The result of this discovery process will dynamically register found Services. For example the SSDP Service Discovery xml-document could contain tags that define a URL to a registration page or possibly the registration markup itself. It is suggested that dynamic services are listed under a separate heading in the UA's Intents picker pop up window.
- Issue 1: The UA's Web Intents implementation must be able to manage the availablility of dynamic Services, i.e. act on when connection with them is lost and when connection is resumed. Should a Service stay registered, but marked as unavailable by the UI, when connection with the Service is lost or should it be un-registered? Is management of Service availability purely implementation specific in the UA or should it be subject to standardization?

Invocation

var channel = new MessageChannel();
var i = new Intent(' http://webintents.org/discover', 
                   "application/octet-stream+mytvprotocol", [channel.port2]); 
navigator.startActivity(i, function(intentData){//Callback is issued by Service when the messaging channel between the Client
                                                  web app and the Service web app is closed} );
channel.port1.postMessage = ...e.g JSON or XML according to mytvprotocol...
channel.port1.onmessage = ....e.g JSON or XML according to mytvprotocol..........

Comments

The messaging channel is allocated by the Client web app. It lives until the Service closes it by issuing intent.postResult and closing the Service application window. This makes the UA to perform the callback on startActivity().

- Issue 2: The proposal assumes that it is possible to transfer a MessagePort from the Client to the Service as Intent payload data. However, the current Intents JS shim from Google and Chrome Intent implementation does not support the possibility to transfer MessagePort as Intent payload data. It must be assured that this is possible to achieve. Alternatively, other ways of persistent anonymous communication between Client page and Service must be defined.

- Issue 3: This scenario assumes that the Client page contains the video play control buttons. The Service receives high level device independent TV control commands on the messaging channel and implements the low level communication, e.g. DLNA, with the specific TV device. However, this type of Service has no UI, it should be invisible to the user. One option is to create the Service as a Web Worker. Another option is to use a hidden iFrame. Irrespective of technical solution it should be possibible to mark "disposition" in the registration markup as "background".

Pros:

Low level protocol agnostic and easy to use for Client web app developers (no dependency on specific low level service discovery and communication mechanisms and no dependency on specific devices).
No information about devices/protocol exposed to the application.
Service implements the low level communication protocol specific to the selected TV device. The UA is not required to support any specific protocol for communication (However, low level discovery and access to low level communication channels still needs to be supported by the UA)
Updates in the high and low level communication protocols can be handled by the Service application without the needs to update the browser

Cons:

Only network protocols supported by the UA can be used (e.g. if the UA does not support UPnP there is no way to communicate with a UPnP device).
Support of newer versions of the protocol requires UA updates.
A Service specific protocol such as "mytvprotocol" must be specified for each Service type supported

Use case: <title>

Steps: <step by step uc description>

Opt 1

Registration

Invocation

Comments

Pros:

Cons:

Opt <n>

...