RE: Mapping WebIntents to Network Service Discovery API

Dave Raggett wrote:
>
> Hi Cathy,
>
> > 7. The latest UPnP event relayed to the Site would indicate that the
> > printer state is "stopped" because it's out of paper. The Site notifies
> > the
> user.
>
> Could you please clarify what you mean by site?  Do you mean the web page
> and its scripts, or do you mean the http server that the web page was
> downloaded from?  My guess is the former, but I wanted to make sure.
Yes I was referring to the web page and its scripts. (I was following
timeless' lead in terminology here.)

> How much knowledge would a UPnP browser be expected to have of
> services delivered over UPnP? For instance would it know about the kinds of
> events associated with printing and be able to present these directly to the
> user?
>
> 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.

> My reading of the discussion on this list is that Web Intents supports the
> remote procedure call idiom, where the user selects the provider that
> receives the call. For the current use case, this call would be the request
> to
> print a given resource.
>
> How can the web page tie a particular UPnP event to a particular print
> request?
In the case of UPnP printing, the UPnP printer would return a Job ID as part
of the action response. Assuming that the UA (or an extension) relays the
response message to the web page (as part of the return data of the Intent
invocation), the web page would be able to extract the Job ID.

>
> There are a number of possibilities for consideration:
>
> 1. The print request could set a call back for notifications, which could be
> used in conjunction with a closure.
>
> 2. The print request could set an object with a method that is called by the
> browser to deliver notifications. This technique is used in Firefox for
> observer
> notifications.
>
> 3. The print request could set an id that is included in the notification,
> enabling web page scripts to relate the notification to the request.
>
> If the browser provides the notification via postMessage, the web page
> script could use window.addEventListener to register a function to handle
> messages. This function would need to examine the origin and data fields of
> each message to determine how to dispatch the message, since the function
> would need to handle all messages delivered via postMessage.
>
> What would be the origin for a UPnP printer on the home network?
What do you mean by origin?

> From a scripting point of view it would be cleaner to have a dedicated
> handler for the specific print request. My preference would be for option 2
> above.
>
> The web intent invocation would presumably look something like:
>
> var intent = new Intent("http://webintents.org/print");
> window.navigator.startActivity(intent, handler);
>
> where handler is an object that supports the notification interface. We
> could
> standardize that interface on a per intent basis, depending upon how much
> knowledge of the intent, the browser needs to have. The handler argument
> is optional, if missing or null, you don't get notifications.
>
> Comments?
>
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett