HNTF/Home Network TF Discussions/Alternatives

From Web and TV IG

Examples and Alternatives for a Generalized HTML-5 Home Networking Interface

In considering solutions for adding home networking functionality to HTML-5 browsers, it will be helpful to consider several possible solutions and work through practical examples to see how the various solutions might be implemented. It is expected that the number of solutions will expand as people come up with ideas and that the number of solutions will decline as their relative merits are compared. Eventually, we should have a few viable solutions from which to choose as we make recommendations.

Example 1: Service Discovery

  1. A web application discovers services on the local network.
  2. As services come online or go offline the changes are dynamically recognized by the web application.
  3. The user agent can recognize services using the set of discovery protocols it supports.
  4. The HTML5 interface provides sufficient information that the discovered services can be uniquely identified and their actions can be invoked by applications that know how to use them.

Solution 1.1: Generic Discovery API

The HomeNetworkTypes[] array contains a list of supported protocols (e.g. SSDP, mDNS/DNS-SD, etc.). The discoveryEnabled action verifies that the user has not disabled discovery. The serviceDiscovery action registers the callbacks for discovery and begins the discovery process. The serviceArrived and serviceDeparted actions are called when new services appear and disappear respectively. 

Interface HomeNetworkServices {
    // Home Network types  supported
    readonly attribute HomeNetworkTypes[] hnNetworks;

    // Discovery control
    boolean discoveryEnabled(); //class variable
    serviceDiscovery(regex to match); //per instance
	
    // Service related events
    HNService serviceArrived(); //per instance
    HNservice serviceDeparted(); //per instance
}

Solution 1.2: Structured Object API

Here is another take on an interface, difficult to split in discovery and communication. This method uses structured objects to pass information. A method exposes a service to the outside, and a structured object is used for the message and its arguments. Note that service action invocation is included here rather than pulled out into a separate example. 

interface HNControl {
        readonly attribute DOMString supportedProtocols[];
        // static list of supported protocols

        readonly attribute HNService discoveredServices[];
        // dynamic list of all discovered services in this session

        void activateServiceDiscovery(HNDiscoverer disc);
        // call this function with null to stop discovery

        HNService createService(protocol, name, type, description, HNMessage set[]);
        // this method creates a service provided by this "page"
        // the array of HNMessage defines the interface of the service
        // only the sendMessage and receiveMessage of the returned HNService are useful
}

interface HNDiscoverer {
        attribute function discoverService;
        // callback with one parameter of type HNService
}

interface HNService {
        readonly attribute DOMString name;
        readonly attribute DOMString type;
        readonly attribute DOMString address;
        readonly attribute DOMString description;

        integer sendMessage(HNMessage msg);

        attribute function receiveMessage;
        // callback with one parameter of type HNMessage

        attribute function serviceAvailability;
        // callback with one parameter of type Boolean
}

interface HNMessage { // generic message, not necessarily structured
        attribute DOMString name;
	attribute DOMString payload;
}

interface HNStructuredMessage extends HNMessage { // structured message, for protocols with service abstraction such as UPnP
        attribute HNArg args[];
}

interface HNArg {
        attribute DOMString name;
        attribute Boolean isInput;
        attribute DOMString type;
        attribute DOMString value;
}

There is nothing in the interface above about migration or distributing documents, as described in the document-level UCs. For migration, a service of type HNTFUA shall be exposed by HNTF user agents. This HNTFUA has at least two messages: migrate(documentURL, stateURL) and suggest(documentURL[, stateURL]). It also makes sense to add a message to exchange capabilities between UAs. 

<serviceDescription type="http://www.w3.org/WebTV/HNTFUA">
    <message name="migrate">
        <input name="documentURL" type="URI" presence="required"/>
        <input name="stateURL" type="URI" presence="optional"/>
        <output name="migrationResult" type="string"/>
    </message>
    <message name="suggest">
        <input name="documentURL" type="URI" presence="required"/>
        <input name="stateURL" type="URI" presence="optional"/>
        <output name="result" type="string"/>
    </message>
    <message name="getHNTFCapabilities">
        <output name="HNTFCapabilities" type="string"/>
    </message>
    <message name="getHNTFDescription">
        <output name="HNTFDescription" type="string"/>
    </message>
</serviceDescription>

The HNTF UA should implement the above service on all supported discovery and service protocols. One goal is to make HNTF UAs discoverable by other HNTF UAs, and implement document migration.

Example 2: Service Action Invocation

  1. A service interface is presented that enables a web application to:
    1. Identify the name of the discovered service
    2. Invoke an action offered by the service
    3. Receive a response from the service action that was invoked

Solution 2.1: Generic Service Action Invocation API

In general, service actions are specific to instances of services. Also, at least two protocols are used to transmit action requests: SOAP and REST. Therefore, service invocation takes two arguments: which protocol to use and the string that constitutes the action invocation. In the SOAP case the string is the SOAP message. In the REST case, the string is appended to the service URL to create the REST action invocation. (NOTE: In some protocols, there is not distinction between serviceName and friendlyName.) 

interface HNService {
    readonly attribute DOMString serviceName;
    readonly attribute DOMString firendlyName;
    readonly attribute DOMString serviceURI;

    void action(in protocolToUse, in DOMString serviceAction);
    actionCallBack(callBackfunc()); // use for action responses and evented variable?
    DOMString  serviceEvents() //don’t need if yes to above
}

A Service Aware Interface

There has been discussion that it would be useful for an API that abstracts service actions, play() for example. This is attractive because it relieves the web application from having to figure out how to formulate a message that invokes the play() function on a service by service basis. It is easy to see how to do this with UPnP services because the set of services and the set of actions on each service is well-defined. This is not the case in DNS-SD. www.dns-sd.org/ServiceTypes.html defines a list of DNS-SD service types but this is a very long list. If a user agent is to present an interface with an abstract play() function, the user agent needs to understand how to map that abstract play() function onto all services that support play(). It does not seem practical for a user agent to know about all of these services, and the list can grow. The alternative is to define a subset that of services to be supported in the user agent. The obvious issue with this is “which subset”.

Retrieved from "https://www.w3.org/2011/webtv/wiki/index.php?title=HNTF/Home_Network_TF_Discussions/Alternatives&oldid=370"