W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

RE: Home Network Service Discovery and Web Intents

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>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D631BF979@seldmbx03.corpusers.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 9 December 2011 15:28:56 GMT