- From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
- Date: Fri, 9 Dec 2011 17:01:09 +0100
- To: Paul Kinlan <paulkinlan@google.com>
- CC: Giuseppe Pascale <giuseppep@opera.com>, "public-web-intents@w3.org" <public-web-intents@w3.org>
I have added option 3 to the wiki now: http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Opt_3 Please comment. Claes > -----Original Message----- > From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonyericsson.com] > Sent: den 9 december 2011 15:59 > To: Paul Kinlan > Cc: Giuseppe Pascale; public-web-intents@w3.org > Subject: RE: Home Network Service Discovery and Web Intents > > 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 16:01:50 UTC