Alternatives

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
}

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”.