Re: Discovery API proposals: call for comments

Dave Raggett wrote:
>
>> This proposal allows discovery and connection to _HTTP_ service
>> endpoints only. Bluetooth and USB would be nice but we decided not to
>> overload this API beyond its intended capability.
>
> Hmm, why single out HTTP in this way, given the widespread availability
> and continuing evolution of other interconnect technologies (e.g. USB,
> Bluetooth, Firewire, NFC, ZigBee)? In what way is HTTP required by the
> interfaces in the current proposal?
>
> A further question. How do you send a message to a discovered network
> service?

A web page can use the value of the 'url' attribute provided in any 
NetworkService object with any existing messaging api such as 
XMLHttpRequest, Web Sockets (to initially set up the socket) or Web 
Messaging (to set up a cross-origin messaging channel).

We apply implicit cross-origin resource sharing privileges to the 'url' 
attribute returned in each NetworkService object to allow for 
cross-origin resource sharing to take place with these existing 
messaging apis.

These communication mechanisms are built on top of a HTTP/TCP stack 
(even the case of Web Sockets requires HTTP initially before upgrading 
to a independant TCP-based protocol) so that's why our proposal is 
constrained to communication with HTTP-based interfaces only: so we can 
reuse existing web messaging APIs to communicate with endpoint URLs 
(with implied cross-origin privileges) provided in each NetworkService 
object.

> The corresponding interface includes the DOM EventTarget
> interface, so I am guessing that you can target an event at the object
> for the network service. This seems a little at odds with the "event
> handler attributes" defined as functions that can be set. Why didn't you
> either stick with DOM events for both notifications and targeting
> events, or instead, stick with functions, and define a method for
> sending a message to a service?

Hopefully the above explanation provides a suitable answer to this part 
also. This is not how it is intended to work. 'url' is used for sending 
messages to the service (and receiving their replies) and 'onmessage' is 
used for inbound event messages sent from the service.

Received on Thursday, 22 September 2011 12:57:59 UTC