W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2015

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 1 Apr 2015 18:02:24 +0200
Message-ID: <CA+c2ei8gNa-rrk60jXpHL07pZLGO83pJ9CcD4C4VU5BYVJDxEw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Domenic Denicola <d@domenic.me>, "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, public-webapps <public-webapps@w3.org>, Device APIs Working Group <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "slightlyoff@chromium.org" <slightlyoff@chromium.org>, "yasskin@gmail.com" <yasskin@gmail.com>
On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola <d@domenic.me> wrote:
>> I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today.
>
> It's true when UX is involved. When UX must not be involved, it's a
> very different situation. For those cases we do spell out what needs
> to happen.

I agree with Anne. What Domenic describes sounds like something
similar to CORS. I.e. a network protocol which lets a server indicate
that it trusts a given party.

Not saying that we can use CORS to solve this, or that we should
extend CORS to solve this. My point is that CORS works because it was
specified and implemented across browsers. If we'd do something like
what Domenic proposes, I think that would be true here too.

However, in my experience the use case for the TCPSocket and UDPSocket
APIs is to connect to existing hardware and software systems. Like
printers or mail servers. Server-side opt-in is generally not possible
for them.

/ Jonas
Received on Wednesday, 1 April 2015 16:03:25 UTC

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