Re: Home Network Service Discovery and Web Intents

On Fri, 02 Dec 2011 18:26:57 +0100, Nilsson, Claes1  
<Claes1.Nilsson@sonyericsson.com> wrote:

> Hi Guiseppe and all,
>
Claes,

> 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".
>
yes, this is my understanding too.

> However, the discussions are much about the abstraction level for this  
> other "persistent" channel.

Not only the abstraction level but also the actual tool to use.
I think that for some levels of abstraction there are still multiple ways  
of achieving the same result (e.g. send soap messages via XHR Vs via  
postMessage).


> 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.
>
Even if you have an high level of abstraction, this doesn't mean you  
cannot communicate with the service you are sending the "video" to.
The protocol used by the service needs to be defined, but at a minimum I  
would expect to be able to know if the video was successfully played (if  
not, I may want to try again or send an alternative link).
This protocol would have to be defined generic enough not to be tied to  
any particular service/network protocol, but this shouldn't be an issue.

[I updated the description to clarify this]

> 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.

could you add it to the wiki? would be really beneficial to have  
everything on the same page.

> 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.
>

I'm a bit confused here on one important point: are you talking about  
implementing UPnP discovery in an external service or the UPnP messaging?  
I.e. do you imagine the "registration" phase to be done like above or just  
the communication?

If you are talking about discovery:
- I agree this is something to explore, could you add it to the wiki? Note  
that this doesn't solve the problem that "someone" have to support one (or  
more) network protocols, but if we define discovery as a service we can  
enable both implementations (inside the UA and in an external service), it  
seems an interesting path to explore. There is one issue I can see here  
though: with an external discovery service is a bit more difficult to  
guarantee what is exposed to applications. Basically the UA rely on this  
externa service not to expose sensitive information.

If you are talking about communication with a (already found) service, few  
comments:

1. I agree that using an "high level protocol" is an option and is exactly  
what I meant in option 1 with "//communicate with the HN device" (I  
assumed the message channel could also be retrieved as argument of the  
callback). In my case though I was proposing to have high level protocols  
for each verb (i.e. for each common use case) and fallback on your  
approach only for less common use cases.

2. About the UA embedded support vs use of an external service: I'm not  
sure we need to make this distinction. A service is a service. An  
application could look for "application/octet-stream+mytvprotocol" and  
talk to it, but the "service" it is talking to may actually be the UA  
itself. Or an external service. It doesn't matter (to the app).

3. Having UPnP support in an external service doesn't solve the orginal  
problem of having "someone" that supports UPnP. I agree though that this  
doesn't necessarily need to be the browser but another service on the web  
or in the home.

4. I'm not sure if we are proposing the same thing or not: do you imagine  
this "mytvprotocol" to be a wrapper around one specific protocol (say  
UPnP) just using json, or would you expect to be a generic protocol that  
can be mapped on different protocols? If the second, how do you think you  
can support the inevitable differences between network protocols (in terms  
of supported functionalities?) Would you expect the have "extensions" to  
the basic protocol for additional functionalities?



> 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/).
>
agree on this

/g

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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Tuesday, 6 December 2011 10:26:52 UTC