- From: Dave Raggett <dsr@w3.org>
- Date: Sat, 14 Jan 2012 13:43:35 +0000
- To: Cathy.Chan@nokia.com
- CC: timeless@gmail.com, public-web-intents@w3.org
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/UPnPEventListener.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 Saturday, 14 January 2012 13:44:37 UTC