[erlang-questions] Two beautiful programs - or web programming made easy

[Masklinn]

On 2011-02-12, at 15:52 , Joe Armstrong wrote:

> 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
>> a client), but the main (and default) communication mechanism in Javascript
>> 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
This referes to what i quoted. The sum is incorrect since some of its parts (namely your assertion that asynchronous client->server communications are "not easy") are incorrect. Which is what I explain in the next three lines.

> - I said we can't easily ... send an
> asynchronous message
> from the server to the client - I am fully aware the HTTP does not support
> this that
> why I said "easily" it can be done with horrible work arounds like comet
> etc.
You also said, in the same bundle, that "we can't easily send an asynchronous message from the client to the server". Which is completely incorrect.

>>> 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.
You said turning off web sockets due to them being broken was stupid. It follows that you advocate releasing and enabling websockets in a broken state.