RE: Mapping WebIntents to Network Service Discovery API

Thanks for your reply Guiseppe,

Yes, there are similarities in yours and Dave's proposals in the sense that the address the need for a persistent communication relation with between the Client web application and the Service. I had a discussion with Dave today and he said that he is preparing a more tangible proposal for the "printing use case" that he plans to provide to the list next week. The basic idea is to use the intent data attribute and provide a “handler” object specific (standardized) for the intent Action. So for a "http://webintents.org/print" action there is a "print_handler" object providing functions for detecting "print completed", "out of paper", "paper jam", etc. 

This is different from your proposal in the sense that the persistent relation between the Client web application and the Service is created with the call to navigator.startActivity() and not as in your proposal when the callback is issued. My impression is that Google proposes that the callback should be issued when the persistent relation between the Client and Service is terminated.

Best regards
  Claes

> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 19 januari 2012 15:47
> To: public-web-intents@w3.org; Nilsson, Claes1
> Subject: 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 Wednesday, 25 January 2012 11:33:42 UTC