Re: Raw sockets feedback from Mozilla Network team

And here's a few replies from me:

> * for the server socket API it should be called "onAccept" instead of
> "onConnect" to match the commonly understood sockets API - accept() is
> the system call you used to take an incoming connection. There doesn't
> seem to be a compelling reason to invent new lingo for well understood
> operations.

I think connect() was used to align with WebSockets. I guess I don't
care strongly, but I'm not a big fan of "accept".

> * on security - we need to think about this a little harder. What does
> it mean to be priv'd enough to use this API? Simply being an installed
> app or being an audited/signed one? The security implications are
> pretty staggering here and I'm pretty sure the answer needs to be more
> than "unprivd js off a webpage can't do this". Our user's privacy is
> pretty much undermined by allowing this.. I know this is desired as a
> backwards looking bridge, but the truth is it brings new functionality
> to the mobile platform and that platform ought to at least be dealing
> only in TLS and DTLS as table stakes.. While I think TLS and DTLS
> ought to be mandatory - at the very least they ought to possible and
> it doesn't really look like that use case has been fully baked into
> the API yet.

I think we need to make more progress on the runtime/security spec in
order to define things better here.

> * I guess I'm also concerned about TCPSocket.send().. the definition
> of it says that if it exceeds an internal buffer of unknowable size it
> must close the socket and throw an error. How can an application use
> that safely if it doesn't know what value will overrun the socket and
> trigger the exception and a close?
>
> Rather than the true/false semantic being used as a return value here
> (which requires the whole send be buffered) it would be traditional to
> let the send accept 0->N bytes of the N bytes being sent and have that
> (0->N value) be the return code. Partial sends are part and parcel of
> stream APIs. That way if I have 4MB to send but you've only got 1MB of
> buffers I don't have to magically guess that - I do a 4MB write, 1MB
> gets buffered - 1MB is returned and I come back later to try and write
> the next 3MB. (either immediately which probably returns 0 or after an
> ondrain event).

One of the design principals for Web APIs is to make things easier for
developers, at the cost of taking more complexity in the platform.

Forgetting to check the return value seems too easy to do and it will
work most of the time, which will lead to hard to track down bugs.

I agree that throwing is the wrong thing to do here. I'd rather think
that the platform should be required to buffer any data that is sent.
Handing out-of-memory should be done the same way here as we do
everywhere else in the web platform, I.e. as a
quality-of-implementation issue.

/ Jonas

Received on Sunday, 25 August 2013 23:36:57 UTC