[erlang-questions] Two beautiful programs - or web programming made easy
Sat Feb 12 15:52:05 CET 2011
On Sat, Feb 12, 2011 at 3:29 PM, Masklinn <masklinn@REDACTED> wrote:
> On 2011-02-12, at 14:03 , Joe Armstrong wrote:
> > As I see it the web is predominantly built with one concurrency pattern.
> > A client (web browser) can do an RPC to a server
> > We can't (easily)
> > do an RPC from the server to the client
> > send an asynchronous message from server to client
> > send an asynchronous message from the client to the server
> This is incorrect. HTTP does not support "push" messaging (from a server to
> is asynchronous (and event-driven). Unless you have a very different
> definition of "asynchronous message" than the one I'm used to.
To what does the word "this" apply?
"this" (ie the first word of your comment) could refer to
any combination of four things - I said we can't easily ... send an
from the server to the client - I am fully aware the HTTP does not support
why I said "easily" it can be done with horrible work arounds like comet
> In fact, synchronous RPC-type calls are definitely frowned upon as they
> single-threaded event loop).
> > Turning web sockets off for security reasons is stupid.
> > The solution is to sandbox the thing that receives the messages
> > or if unsandboxed strongly authenticate the messages.
> I don't follow you here. You're saying it's OK to release broken standards
> (even though they're fixable) and asserting that every implementor should go
> through the process of creating his own broken sandbox which will fail to be
> correctly secured?
I didn't say it was ok to release broken standards.
I didn't say "broken sandbox" I said "sandbox" - If you want to be secure
you should put
every application in a trusted sandbox. That way you can play with web
sockets even if they
are broken. You need a security policy for your sandbox that disallows
access to local storage, opening new socket etc.
More information about the erlang-questions