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.


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.

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

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?

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?

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

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



/g

[1]  
http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Use_case:_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 07:40:54 UTC