W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

Re: Extending Network Service Discovery draft with advertisement

From: Bryan Sullivan <blsaws@gmail.com>
Date: Mon, 12 Mar 2012 08:36:35 -0500
Message-ID: <CAA2gsfpLudDnhK6GZb2vs5kcbmiNV93bDqtBSUDeA+4C_A6Log@mail.gmail.com>
To: Rich Tibbett <richt@opera.com>
Cc: Jan Lindquist <jan.lindquist@ericsson.com>, Clarke Stevens <c.stevens@cablelabs.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Rich, as below the referenced req doc describes the use case pretty
well, but perhaps we can dive a little deeper e.g. if someone has a
demo that they've done re something similar we can get a few more
details as to how that was done.

The protocol handler registration of HTML5 (and also content hander,
both are addressed by
http://www.w3.org/TR/html5/timers.html#custom-handlers) is a specific
exposure approach based upon advertisement of a URL scheme or MIME
type handler capability by a website, via the registerContentHandler()
method. In the use case below, how do you think this website
(HTML+Javascript) content from the advertising device could get to the
other devices in the HN, so that it could advertise itself? Would all
the discovering devices have to browse to all the other devices
somehow, or is there an automated way to make this happen under
HTML5's API for this?

From: http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#u6.-application-exposing-a-service
"An application exposes a service on the home network. In order to
allow this with some technologies, it may be necessary for the HNTF
user agent to advertise itself on the HN as a device. For example, an
application rendered on a connected TV has access to the connected TV
API for EPG information. Other devices on the HN do not have access to
this information. The application implements a service exposing the
EPG information and makes it discoverable by other devices.

Possible implementation:

the application A is a TV-broadcast-related application, which is
allowed to call the function returning the description of the next
program.
the application A exposes a service with one message getNextProgramDescription.
application B on another device discovers the service (not knowing
that it is an application, it is just another service to application
B).
Neither application A or B know the actual nature of the other. They
may have an IP address, and they share a service type."



On Mon, Mar 12, 2012 at 7:27 AM, Rich Tibbett <richt@opera.com> wrote:
> Jan Lindquist wrote:
>>
>> Hi,
>> Even though this is only a draft I would like to suggest to extend the
>> draft "Network Service Discovery and Messaging" with advertisement
>> support.
>> Reference to original draft
>> _http://people.opera.com/richt/release/specs/discovery/Overview.html_
>> The proposal is to update section 9 Use Cases and Requirements with a
>> new requirement that is in line with the requirement specified in
>> published "Requirements for Home Network Scenarios".
>> Reference to published requirements
>> _http://www.w3.org/TR/2011/NOTE-hnreq-20111201/_
>> The requirements to be added are according to the following two sections
>> 1. _http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#services-advertisement_
>> 2.
>>
>> _http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#u6.-application-exposing-a-service_
>> If this is agreed then I will contribute with the necessary changes to
>> provide the support.
>
>
> Perhaps you could describe in more detail the use case here? Is this about
> web apps advertising themselves as Local Network Services? That is something
> I'd particularly like to see proposals for so please forward them here and
> we can discuss them further. For the most part that's something that I see
> registerProtocolHandler doing [1].
>
> Best regards,
>
> Rich
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
>



-- 
Thanks,
Bryan Sullivan
Received on Monday, 12 March 2012 13:37:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC