RE: Home Network Service Discovery and Web Intents

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