- From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
- Date: Fri, 9 Dec 2011 15:58:48 +0100
- To: Paul Kinlan <paulkinlan@google.com>
- CC: Giuseppe Pascale <giuseppep@opera.com>, "public-web-intents@w3.org" <public-web-intents@w3.org>
Thanks for your response Paul. This makes sense. I will update the wiki page, http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents, with an option 3 for the "push play" use case. Regards Claes > -----Original Message----- > From: Paul Kinlan [mailto:paulkinlan@google.com] > Sent: den 9 december 2011 15:26 > To: Nilsson, Claes1 > Cc: Giuseppe Pascale; public-web-intents@w3.org > Subject: Re: Home Network Service Discovery and Web Intents > > On Fri, Dec 9, 2011 at 1:29 PM, Nilsson, Claes1 > <Claes1.Nilsson@sonyericsson.com> wrote: > > > > Hi Giuseppe and Paul, > > > > Comments inline below. > > > > Claes > > > > > -----Original Message----- > > > From: Paul Kinlan [mailto:paulkinlan@google.com] > > > Sent: den 6 december 2011 18:44 > > > To: Giuseppe Pascale > > > Cc: public-web-intents@w3.org; Nilsson, Claes1 > > > Subject: 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). > > > > Yes, I agree > > > > > > > > > > > > > > > > > >> 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..... > > > > Paul, so you mean that if a "persistent" communication channel is > needed between the Client and the Service then this channel should be > created by the Client and the id of this channel is included as payload > data with the Intent? Basically as my example code above? However, I > need to understand the lifecycle of this "persistent" communication > channel. Do you mean that the "persistent" communication channel is > closed when the Service posts the result data and the startActivity > callback function is executed? > > Yes. I am saying that rather than receive a channel in the callback of > startActivity, the client application will set up the channel to > communicate across. The MessageChannel API doesn't have to have an > endpoint when it is created. > > Our current thinking is that when the service calls postResult() the > channel is closed since in the standard request/response model the > data has been sent back. Obviously with MessageChannel's you can open > and close the ports as and when you feel like, but postResult is > similar to closing the window of the service. > > The example code above is something that I would expect to see. > > > > > Giuseppe, regarding your question about implementing UPnP discovery > in an external Service or the UPnP messaging I think that both may > apply. I imagine that if I have one or more TVs or "screens" that can > show videos in my home each one of them could be handled by a specific > Service web application that implements the low level service discovery > and communication mechanisms supported by the specific "screen" device. > The Client web application talks with the selected Service web > application through the high level "mytvprotocol" on the messaging > channel allocated by the Client web application and the Service web > application implements the low level discovery and communication > protocol. As you say there might be security implications on this > approach but I know too little about UPnP and similar to say so much > about this. > > > > > > > > > > > > > > > 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. > > > > Yes, I agree on above. > > > > > > > > > > > > > > > > > 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. > > > > > > > I interpret the main idea with Web Intents so that a Client > application issuing an Intent should not have to know anything about > the low level service discovery and communication details of the > Service selected by the user. So the protocol run on the messaging > channel should basically be generic. If I understand you correctly Paul, > you are proposing an additional and optional possibility for Clients to > use protocols tailored to specific devices? Is this correct? > > I am saying that the protocol being used to transport data to the > devices should be the same that is specified in the data type > attribute. If "application/tv+something" is an set of XML messages > then they are just XML Messages sent over the message channel. If it > is binary data, then they are Blobs sent over the message channel. > > This message channel is just a generic channel, the protocol on the > channel can be very specific, it is expected that applications either > side of the conversation know and understand the protocols being used. > > > > > > > > > > > > > > > > > > > > > > > > > > >> 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. > > > > > > > > > > Yes, I agree on this approach but I am not sure that > "application/tv+octetstream" need to be complex. There is also a > possibility to create Javascript library APIs on top of this to provide > convenience for web developers. > > > > For sure, I expect libraries and widgets to built on top of web > intents. "application/tv+octetstream" was just an example for > something that is a higher level protocol - I would expect the > application/tv+* types to represent the name of the specific protocols > being used. > > > So, as a summary I can update the wiki page with conclusions from > this discussion but before that I would like to hear your response to > this mail. > > > > > > > > > > > > > > > > > > /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 Friday, 9 December 2011 14:59:30 UTC