Fwd: Home Network Service Discovery and Web Intents

[Sorry sending as plain text]
Hi,

Comment right at the end.

On Tue, Dec 6, 2011 at 10:26 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
>
> 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.


The callback should generally return the same type of data that it
sends to the application, so for instance if you edit an image if you
get a callback it should be an image.  On another note, the execution
of the callback in startActivity, essentially means the users has
completed their task, so a message channel in the case wouldn't
help.....

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


Agree, and I think we should try and keep it this way. We were
proposing that we have the three levels request, request and response,
MessageChannel.  What goes over the message channel could be
aribitrary, but if you agree on the type i.e, the "+mytv" then you are
essentailly agreeing on the data types and protocols being used....
but can stay outside the scope of the intent spec and rather be pushed
in to protocol on top of intents.

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


I would say you use the type encoding to informally agree on the
protocol being used to talk with the device and then use that to send
message across.  The theory is that if the developer of the client app
specifies some esoteric API then they know they are doing this as an
explicit choice and can therefore form their messages correctly.  If
not, the remote device or app should ignore the messages.

This should in theory cover the aplication/* data type where I as a
client app developer say that I want to find all services that support
anything under application - this means they could find a TV and start
sending the wrong messages to it, which the TV should drop and close
the connection.

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


The definition of complex protocols is something that we tried to
fiercely stay away from when determining the original scope of web
intents, and I propose that individual protocols not take over the
core of the web intents API.

My thoughts generally, if I want to share a url with my TV screen -
because that is a kind of awesome use case - I (as a client developer)
want to know that that I just do the same thing as I would do for
twitter sharing, that is have an intent "share", data type
text/uri-list and the url.  The UA would load the service picker and
would have to know how discover the device in the picker AND send it
the correct data so that it could open up the page.

I as a developer don't want to have to have an intent for sharetv,
with a "application/tv+octetstream" data-type unless I am developing a
specific app to talk to TV's.

So supporting the flexibility of "share" with a simple data argument,
or "sharetv" with a complex protocol on top of it is something that I
think we can support, but is something vendors of the hardware or the
UA will have to agree to support outside of the scope of web intents.


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



--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan




--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Tuesday, 6 December 2011 17:44:50 UTC