RE: Home discovery over Web Intents: current status and next Steps

Thanks for this summary Giuseppe,

See my replies inline below.

Regards
  Claes

> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 29 mars 2012 09:40
> To: public-web-intents@w3.org
> Cc: Nilsson, Claes1; Rich Tibbett
> Subject: Home discovery over Web Intents: current status and next Steps
> 
> Hi,
> this is an attempt to summarize the discussion so far and see where we
> agree and where we disagree and what still needs to be better worked
> out.
> 
> Claes/Rich: since I didn't attend the F2F would be good if you could
> comment on the points below in case you had a chance to talk about them
> during the F2F.
> 
> 
> 0. Legacy Devices:
> Do we aim to support legacy devices already deployed?
> I say yes. What do you think?
> 
> 1. Plugins:
> 
> I don't think it make sense to discuss plugin based solutions. This
> doesn't mean UA support is not needed.
> To be specific: I don't think discovery should be done by the
> application.
> It should be the UA responsible for it.

I agree that the application should not perform local network discovery and native support for common service discovery protocols in the UA is preferable. However, I don't think that we should exclude the possibility to support for example UPnP/SSDP discovery using an in-device web server. For example, the Webinos EU-project platform includes an architectural component called Personal Zone Proxy that is based on node.js and provides a lot of interesting functionality, e.g. secure access to local APIs. For Android we have a port to Android (anode). 

However, is this an issue that is subject for standardization? Isn't this an implementation issue? So shouldn't the standard define UA support for service discovery protocols such as UPnP/SSDP but not whether this is implemented natively or through some other in-device component? 

> 
> 
> 2. Activity start
> As me and Claes tried to highlight in [1] there are at least 3
> different
> approaches to this (and there could be more). And I don't think they
> are
> mutually exclusive.

Yes, I agree.

> 
> A. Verb :
> Intent("http://webintents.org/view",“video/mp4v”,“http://example.com/vi

> deo");
> 
> I think this is already implicitly supported by web intents and it will
> allow UA to support the simple use cases without app developers having
> to
> bother about Home Network devices (or native apps).
> The question is if anything else needs to be specified to support this.
> You propose some extensions to UPnP. I feel that a simple table mapping
> "well known" services to "well known" verbs should be enough for
> implementers.
> 
> => What do you think? Is anything more needed?

I think that we should explore both possibilities, i.e. both of mapping of existing SSDP description document tags to web intents service items, as well as extensions to the description document. Section 2.5 of the " UPnP Device Architecture 1.0" describes how "Non-standard vendor extensions" could be added to the description document. I need to look more on this but my assumption is that we could add tags here and prototype. 

I have an action to create a Web Intents addendum specification on extensions to the UPnP description document, http://www.w3.org/2009/dap/track/actions/510


My interpretation of the action that was given to you, http://www.w3.org/2009/dap/track/actions/511, is that it is about defining a mapping of existing SSDP description document tags to web intents service items.

> 
> B. Real Protocol : new
> Intent("http://webintents.org/discover","urn:upnp-
> org:serviceId:AVTransport");
> C. Abstract Protocol: new Intent('
> http://webintents.org/discover',"application/octet-
> stream+mytvprotocol");
> 
> I'm not sure of the advantage of C over B at this point.
> 
> If we are going to make our own protocol we need to make sure that this
> is
> comprehensive enough to cover all the use cases we are targeting.
> Since this discussion didn't started yet for "simpler" intents (I've
> only
> seen one proposal about contacts and one fight over Sensors ;) ) I'm
> not
> sure B is a good starting point.
> I would rather start from C. If the approach C is proved to be working,
> you haven't wasted your time because most (all) of your code will be
> reusable and there will still be cases of exotic devices where you need
> to talk a specific protocol and not invent your own general protocol.
> 
> Once we have a bit of experience with C, we could start to work on a
> generic protocol. Thoughts on this?

Sounds reasonable. Implications on the standard is to be analyzed. What is subject to the main Web Intents specification, to UPnP (and other) addendum specifications, to "tv control" protocol specification and what are pure implementation issues?

> 
> 3. Device VS application
> 
> Are we aiming for app-to-device communication or app-to-app
> communication?
> This was not clear to me by just looking at the slides in [3]

In [3] it differs between the different proposals:

- Proposal starting at slide 8: Service app communicates with remote device (control commands over xhr or web sockets)
- Proposal starting at slide 15: Client app communicates with remote device (control commands over xhr or web sockets)
- Proposal starting at slide 21: Client app communicates with Service app over message channel and Service app communicates with remote device (control commands over xhr or web sockets)

> In [2] we aim for both. So there is no assumption that the home devices
> is
> running a web server with an application. This seems to be the main
> difference from the traditional web intents architecture.
> 
> 4. Communication
> 
> A. Message Channel
> 
> navigator.startActivity(i, function(intentData){
>     channel.port1.postMessage = ...
>     channel.port1.onmessage = ....
> }
> 
> B. URL
> window.navigator.startActivity(intent, function (data) {
>     descriptionUrl = data[0];
>     //extract device description and control URL using XHR
> 
> });
> 
> A or B? (or both?). In the case an app talks to a device, can A
> actually
> work without requiring a "fake" service page generated by the UA?

For A our proposal is that a hidden Service page is created using the additional <intent> tag in the SSDP description document. My understanding of message channels is that it is about communication between two browsing context within the same UA.

> 
> 5. Misc
> Other things I don't see addressed in [3] and I would like to discuss:
> - [2] allows to get a list of services, in the intent approach is
> always
> one service a time. Is handling list of services required?

With the intents approach only one service at a time handles the requested Action. 

> - [2] allows to know when a device goes online/offline. Is this
> required?
> Can be handled differently?

We discussed this at the F2F. Yes, the UA must handle the availability of dynamic Services. For web intents this means managing the list of available dynamic Services in the web intents Service picker but I guess that it is up to the different Service implementations to handle service availability when control communication is running.

Currently it is unclear what should be standardized and what should be left to specific UA implementations.

> 
> 
> 
> /g
> 
> [1]
> http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Use_ca

> se:_push_play
> [2] http://people.opera.com/richt/release/specs/discovery/Overview.html

> [3]
> http://www.w3.org/wiki/WebIntents/SonyMobile_-

> _Local_Network_Service_Discovery
> 
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software

Received on Thursday, 29 March 2012 13:45:57 UTC