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:27:03 UTC