Re: Mapping WebIntents to Network Service Discovery API

On Thu, 19 Jan 2012 11:49:13 +0100, Nilsson, Claes1  
<Claes1.Nilsson@sonyericsson.com> wrote:

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

I agree with your analysis (also with the part I removed)

> 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?
>
I think is possible but may require small changes to Intents architecture.

> 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)?
>
That is what I was more or less proposing in [1] when I describe a  
paradigm like

var intent = new Intent("http://webintents.org/view",  
"video/*","http://example.com/video");
window.navigator.startActivity(intent,function(reply){
   //communicate with the HN device
});

The idea (and is probably what Dave was suggesting as well) is that the  
"onsuccess" callback takes a parameter that can be used for the "next  
step".
For "normal" intents the reply could simply contain the data you need as in

var intent = new  
Intent("http://webintents.org/edit","text/uri-list;type=image/jpeg",  
getImageDataURI(...));
navigator.startActivity(intent, imageEdited);

function imageEdited(reply) {
   document.getElementById('image').src = reply.data;
}

if the selected service is not a web app, this reply could contain the  
needed information to establish a communication channel

var intent = new Intent("http://webintents.org/view",  
"video/*","http://example.com/video");
window.navigator.startActivity(intent,function(reply){
   if(reply.protocol=="upnp"){
    //communicate with UPnP service
   }
});

the above could be use also for web apps, since before start sending  
messages to the app you may want to know which protocol you need to talk.

Does this make sense or is there something I'm missing that makes this  
approach not viable?

/g

[1] http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents

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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 19 January 2012 14:47:26 UTC