Oh, I should add one thing.

I think that the TCPSocket and UDPSocket APIs are great. There is a
growing number of implementations of proprietary platforms which are
heavily based on web technologies. The most well known one is Cordova.
Platforms like those were the original audience for the TCP/UDPSocket
APIs and I think they would work great there.

But of course it requires that those platforms are interested in
implementing a cross-platform API, even it's its not a web API in the
traditional sense.

It might also mean that the API isn't well suited for discussion in
the WebApps WG. I'll leave that discussion to others.

/ Jonas

On Wed, Apr 1, 2015 at 8:47 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola <d...@domenic.me> wrote:
>> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>>> This particular example sets of alarm bells for me because of virtual 
>>> hosting.
>> Eek! Yeah, OK, I think it's best I refrain from trying to come up with 
>> specific examples. Let's forget I said anything...
>>> As in, this seems like precisely the sort of thing that one browser might
>>> experiment with, another consider an XSS security bug, and then we have
>>> content that depends on a particular browser, no?
>> My argument is that it's not materially different from existing permissions 
>> APIs.
> I think it is.
> In cases like geolocation or notifications, the people writing the
> spec, and the people implementing the spec, were able to envision a
> reasonable permissions UI.
> For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to
> describe a reasonable UI.
> Basically the spec contains a big "magic happens here" section. That's
> always bad in a spec. For example, it'd be bad if the CSS spec said
> "figure out column sizes would make the table look good". The fact
> that we're talking about permissions doesn't make magic any more ok.
> Magic is different from leaving UI details up to the browser.
> / Jonas

Reply via email to