Re: [Fwd: local device discovery - api, demo and source code]

Yes, that would work well enough for interbrowser HN interaction, but my
primary concern is supporting (at least) UPnP 1.1 in a manner that provides
as full as possible access to all protocol elements, both for
unicast/multicast notifications/events and unicast request/response
interactions.

At present, CEA-2014-B [1] Section 5.12 defines a JS API that provides most
of such access. Now I would not necessarily advocate the direct adoption of
this API, but I would like to see the features supported by this API
maintained in whatever solution is promoted in the HN TF. To support this,
close attention will need to be paid to security issues (including CORS) as
you note.

I realize 2014-B is not available for free, so I am attaching is my own
transcription of the 2014-B HN interface.

G.

[1] ANSI/CEA-2014-B
Preview<http://www.ce.org/Standards/ANSI_CEA_2014_B_Final_Preview.pdf>

On Sat, Apr 16, 2011 at 5:45 PM, Dave Raggett <dsr@w3.org> wrote:

> Hi Glenn,
>
> In my demo, I thought about passing the received SSDP datagrams to the
> web page script, but soon realized that the same origin policy would
> prevent the script from being able to retrieve the XML description
> without some ugly hack, as current UPnP devices don't implement CORS
> [1]. I therefore chose to retrieve the XML description in the plugin
> code via a worker thread, and pass the XML source to the script.
>
> It would be very easy to introduce a means to support inter browser
> communication across local area networks. This could be exploited for
> games and a variety of applications.
>
> For browser to browser eventing on local area networks, where you can
> send a JSON encoded event to a specific browser via a unicast message or
> to all that are listening via a multicast message, the demo script would
> look something like:
>
> var message_hub = {
>  receive: null, // message delivery handler
>
>  // to is a string for an IP address, this
>  // argument is omitted for multicast events
>  send: function (object, to)
>  {
>    var plugin = document.getElementById("my_plugin");
>    plugin.send(message_hub, JSON.stringify(object), to);
>  },
>
>  // called by the plugin on receiving a message
>  dispatch: function (message, from)
>  {
>    if (message_hub.receive)
>      message_hub.receive(JSON.parse(message, from);
>  }
> };
>
> where the above is hidden in a library included by the web page. The
> multicast address and port for the service would be registered with
> IANA. The above functionality could be standardized as a new object
> available as a property of the Window object.
>
> A more sophisticated approach would allow you as a web page developer to
> designate a markup element as a message hub. You could then register DOM
> event listeners to handle incoming messages, and send events by
> targeting events at the hub. The library script would look for elements
> with a given attribute and add the above behavior. This is feasible as
> the DOM allows scripts to define new kinds of events. We could then
> standardize the attribute and the event format.
>
> Note that the library could be written to start and stop listening when
> the web page registers a listener or removes that listener. This could
> be implemented via a function exposed by the plugin that takes the
> listener count as an argument.  The use of UDP datagrams imposes
> practical limit of a little over 1000 bytes to avoid packet
> fragmentation. The existing Web Sockets API would be used for larger
> messages, or for a streamed connection with a given browser.
>
>
> [1] http://www.w3.org/TR/cors/
> --
>  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>
>