RE: Mapping WebIntents to Network Service Discovery API

Hi,

When reading all mails on Web Intents for "Home Network"/local Services use cases I see a problem that people have different views on what a "Service" in the context of Web Intents really is.

In the context of http://webintents.org/ and the draft W3C Web Intents specification, http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html a Service is defined as a registered "web page which can handle a Web Intents, possibly returning a piece of data to the calling Client page". This definition is very clear, i.e. a Service is a web page.

Based on above I wanted to explore how a local resource could be utilized as a Web Intents Service so I experimented with the "Pick" Intent for picking an image by creating a Service web page that accesses the device camera (for Android through an internal web server as the Camera API was not yet implemented), http://www.sepicker.appspot.com/. So access to a local resource could be performed through a Web Page that uses any underlying mechanisms to access the physical resource.

Theoretically we could implement "Home networking use cases" with Web Intents Services created as web pages that uses low level discovery mechanisms to discover and communicate with devices and services. For example a TV Service could be a registered web page that the Client web page discovers through the Web Intents framework. The TV Service web page could then use any underlying discovery and communication mechanisms, e.g. SSDP/UPnP, towards the physical TV. How this is done, through native implemented browser APIs or through a local web server or whatever, would be implementation specific. Communication between the Client web page and the Service web page could be executed through the Intents payload data or through a persistent HTML5 web messaging channel.

However, the approach above is not very practical and user friendly. Discovery of local network, locally connected or in-device resources is a dynamic process and the concept of Services as registered web pages does not work very well. Therefore it has been suggested that the Web Intents framework in the UA should implement common well-known service discover protocols such as UPnP/SSDP, Bluetooth SD etc, and that the Web Intents framework should be able to dynamically discover local devices/services and register them as selectable Web Intents Services. These types of Services are different from the Services as currently defined in the Web Intents draft specification as they are not web pages and they don't have to implement a user interface.  

It seems as there is support on the Web Intents mailing list for the idea of handling web Intents according to the following two options:

1. Discover Service - Execute action - End 

2. Discover Service - Start action and establish persistent relation between Client and Service - Execute control commands - End

Assuming above is correct the discussion is much about how to achieve a persistent relation between Client and Service. HTML5 web messaging has been proposed and it fits the use cases when a Service is a web page but probably not when the Service is dynamically created by the Web Intents framework itself. My main point with this mail is to highlight the different views we have on what a Service in Web Intents context is and to state that we must find solutions that allows Client web applications to discover and use Services irrespective of whether they are accessed through a local communications method such as Bluetooth, accessed through a local network or situated in the cloud. Is this goal possible to achieve?

Dave proposes below a "handler" object that could be standardized per Intent type, e.g. "print_handler" that has functions to handle notifications from the printer on "finished printing", "out of paper", "paper jam", etc. Alternatively, there could be a general "handler" object for the used low level communication method, e.g. "UPnPEventListener". I like Dave's idea on a "handler" object and spontaneously I would say that this model would work both for the case when the Service is a web page as well the case when the Service is dynamically created by the Web Intents framework. Would it possible to provide the implementation of "handler" objects for different Intent types as JavaScript libraries (assuming that the UA supports APIs for low level access protocols)? 

Comments?

Claes


> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: den 14 januari 2012 14:44
> To: Cathy.Chan@nokia.com
> Cc: timeless@gmail.com; public-web-intents@w3.org
> Subject: Re: Mapping WebIntents to Network Service Discovery API
> 
> On 13/01/12 21:15, Cathy.Chan@nokia.com wrote:
> >> Dave Raggett wrote:
> >>
> >> My guess is that the browser would only have limited knowledge of
> >> the basic UPnP mechanisms. In which case it would need a way to
> >> communicate UPnP events to the web page scripts to act upon.
> 
> > I think that would most likely be the case. The UA (or an extension)
> > will simply relay the complete message from the UPnP device to the
> > web page. If the web page is aiming to use UPnP devices, it would be
> > able to parse and interpret UPnP messages properly.
> 
> Here is a Java UPnPEventListener interface:
> 
> 
> http://www.osgi.org/javadoc/r4v42/org/osgi/service/upnp/UPnPEventListen

> er.html
> 
> We could define something similar for web page scripts. A UPnP event
> has
> a device Id, a service Id and a set of name/value pairs for state
> variables. This could be passed to the script as a couple of strings
> for
> the Ids, and an associative array for the name/value pairs.
> 
> What did you think of my suggestion that the web page passes a handler
> interface to startActivity:
> 
>  var intent = new Intent("http://webintents.org/print");
>  window.navigator.startActivity(intent, handler);
> 
> where the web page script previously declares "handler" as an object
> with the notification interface as suggested above, e.g.
> 
> var handler = {
> 
>   UPnPEventListener: function (deviceId, serviceId, state)
>   {
>      // do something useful with the notification
>   },
> 
> };
> 
> A basic print template for UPnP can be found at:
> 
>   http://www.upnp.org/specs/pntr/UPnP-pntr-PrintBasic-v1-Service.pdf

> 
> This shows that, for example, the PrinterStateReasons variable is a
> list
> of values such as "media-jam", "media-empty" and "marker-supply-empty".
> 
> The basic printer template supports a number of actions such as
> CreateJob, CancelJob, GetPrinterAttributes and GetJobAttributes. The
> CreateJob action takes a set of name value pairs and returns with
> values
> for the JobId and DataSink. The latter is a URL for the client to send
> the print data to via HTTP POST.
> 
> A UPnP action takes the name of the action and a set of name value
> pairs, and returns a set of name value pairs. There are a number of
> ways
> this could be mapped into JavaScript. The returned values will need to
> handled asynchronously to avoid the risk of stalling the UA.
> 
> In principle, the UA could read the UPnP service description and
> dynamically set a function for each action as part of the above handler
> object. Alternatively, there could be a generic function for all
> actions, together with some kind of service handle set by the UA.
> 
> We could choose to define print is a standard web intent along with a
> standard interface for notifications, cancelling a job, etc. I would be
> happy to explore that in more detail. In principle, support for
> standard
> intents could be built into the UA or provided via an extension.
> 
> We also need to think about non-standard web intents and how these can
> be supported over UPnP. For these, the UA would need to expose the UPnP
> service to scripts. This presents a range of possibilities for us to
> explore. The UA could provide a generic means to invoke actions and to
> process notifications. The UPnP service description could be exposed in
> its raw XML form, or there could be lighter weight means for scripts to
> determine the list of actions and state variables. The ServiceId could
> be used as a basis for a predetermined API without the need for
> reflection.
> 
> When it comes to standardizing web intents, we could define a generic
> means to create an Intent and start an activity, and defer the
> standardization of the interfaces for particular events to separate
> standardization efforts. In this way we just need agreement on an
> optional second argument to history.startActivity, and can define the
> interfaces that argument supports in separate W3C Working Drafts.
> 
> A print intent is associated with more complex behavior than a view
> intent, so this separation of effort would seem to make sense.
> 
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Thursday, 19 January 2012 10:49:44 UTC