RE: Home Network Service Discovery and Web Intents

Hi Guiseppe and all,

I have read the wiki page, http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents, and I think that this is a good tool to get further on the analysis of Web Intents for the Home Network use cases.

A general conclusion from the discussions on this mailing list seems to be that Web Intents is a pure discovery and service selection mechanism only. So, when discovery and user service selection is done any further needed communication between the Client web application and the Service web application is done by some other "persistent" channel than the Web Intents "payload channel".

However, the discussions are much about the abstraction level for this other "persistent" channel. In the use case "push play" at http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents two options are presented:

Option 1: An option with a high level of abstraction which makes it easy for the Web Developer as he/she does not have to know anything about low level communication details but requires the UA to implement the low level protocol, e.g. UPnP needed. This option also seems limited to the pure "view video" use case but I am not sure that I understand what "//communicate with the HN device" means in this context.

Option 2: An option with a lower level of abstraction forcing the web developer to search for a service supporting a specific protocol but does not force the UA to implement specific protocols as this protocol is implemented by the Client web application. 

However, looking at option 2 I see no reason why the application developer should have to know about and implement UPnP or similar. We also don't want to restrict the search so that the client application should have to specify the type of discovery and protocol the service uses. The only interest from the Client application is to play a video on a screen selected by the user. So for this use case I see a third option. This relates to earlier discussions at this mailing list on persistent relations between Client web applications and Service web applications. A goal is to make it easy for application developers but still we don't want the UA to have to implement a set of lower level protocols. So, we could instead let the lower level protocol, e.g. UPnP, implementation be done in the Service web application and use a simple high level protocol over the message channel.

Something like:

var channel = new MessageChannel()
var i = new Intent(' http://webintents.org/discover', "application/octet-stream+mytvprotocol", channel.port2) navigator.startActivity(i);

channel.port1.postMessage = ...e.g JSON according to mytvprotocol...

channel.port1.onmessage = ....e.g JSON according to mytvprotocol..........

This means that the web application code implements the simple "mytvprotocol " and is independent of the details of the TV service. The TV service web application implements the UPnP or similar protocol.

As concluded before this approach means that a set of protocols need to be specified in addition to the core Web Intents specification . Something similar to the Bookmark Introducer protocol example that was specified for the Web Introducer (http://web-send.org/bookmark/).

What do you say?

Regards
  Claes



> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 23 november 2011 18:51
> To: public-web-intents@w3.org
> Subject: Home Network Service Discovery and Web Intents
> 
> Hi all,
> as I mentioned in another thread I would like to start exploring this
> topic a bit more in details.
> 
> The starting point of this discussion is a a collection of use cases
> that
> people in the Home Network TF of the Web&TV IG have been working at in
> the
> last months
> http://dvcs.w3.org/hg/webtv/raw-file/ed956fac0f9c/hnreq/hnreq.html

> 
> I've started to put together some thoughts on the wiki
> http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents

> 
> I'm not finished with it but since there is interest in starting this
> discussion, I'm sharing it now.
> 
> My aim at this point is not to try to cover all use cases but just
> focus
> on a couple of them to try to sort out the first major architectural
> issues.
> After that we can try to go more into details and add more use cases on
> the list.
> 
> Comments are welcome. I'm not sure how people prefer to discuss this,
> maybe I can reply to this mail with few questions.
> Anyway feel free to add content yourself to the wiki or fix any
> mistakes
> 
> /g
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software

Received on Friday, 2 December 2011 17:27:40 UTC