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

Re: Home Network Service Discovery and Web Intents

From: Paul Kinlan <paulkinlan@google.com>
Date: Tue, 6 Dec 2011 17:42:51 +0000
Message-ID: <CADGdg3DcxTzbJ+Joa5vvXTmrA4Tbg04TQyDZ3qbSEG-=MTD1rQ@mail.gmail.com>
To: Giuseppe Pascale <giuseppep@opera.com>
Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>, "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
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 <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<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).
>
>
>
>  In the use case "push play" at http://www.w3.org/wiki/**
>> WebIntents/Home_Discovery_and_**Web_Intents<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.....


>
> 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.


>
> 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.


>
>
>
>
>  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.



>
>
> /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<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<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
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan
Received on Tuesday, 6 December 2011 17:43:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 6 December 2011 17:43:35 GMT