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

[Joe Armstrong]

On Sat, Feb 12, 2011 at 4:40 PM, Masklinn <masklinn@REDACTED> wrote:

>
> 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.
>

How the heck can you easily send an an asynchronous message from a client to
a server?

HTTP get and post wait for a reply and thus are synchronous.

By asynchronous I mean "fire and forget" like UDP.

If it easy easy them I'd love to know how ..


>
> >>> 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.


I never mentioned "releasing" or "enabling" in my post so you can't say
I advocated either of these. I said turning them off was stupid - nothing
else.

Actually i wasn't bothered about whether they were broken or not. I was
advocating using them because they are useful. And turning off something
that is useful
is stupid. Windows, for example, allows viruses (by stupid design) but it is
still useful.

Virtually all software I've ever seen is broken in one way or another. It
can still be
useful even if it is broken. It's not a question of absolutes here.

Even if they are broken they are still useful and i can easily put a layer
of strong crypto
on top if I were worried - which I'm not.

/Joe