Two beautiful programs - or web programming made easy

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Two beautiful programs - or web programming made easy

Joe Armstrong-2
Two beautiful programs

For a long time one of my favorite Erlang program was this:

loop() ->
    receive
        F -> F(),
    loop()
    end.

It's nice because it does very little, but what is does is universal. It
enables mobile code.

Well now I can do this in Javascript.

The Javascript equivalent is:

   function onMessage(evt) {
      eval(evt.data);
   }

Where the data comes from a websocket.

Websockets are controlled with a simple API:

      websocket = new WebSocket(wsUri);
      websocket.onopen = function(evt) { onOpen(evt) };
      websocket.onclose = function(evt) { onClose(evt) };
      websocket.onmessage = function(evt) { onMessage(evt) };

Linking a websocket and Erlang is pretty easy. So now I can write code like
this in
erlang

-module(demo1).
-export([start/1]).

start(Pid) ->
    Pid ! {eval, "document.body.innerHTML='';"},
    Pid ! {eval, "document.body.style.backgroundColor='#eeffaa';"},
    Pid ! {eval, "document.body.innerHTML+='<h1>Hello World</h1>'"},
    event_loop(Pid).

event_loop(Pid) ->
    receive
    Any ->
        io:format("??event loop:~p~n",[Any]),
        event_loop(Pid)
    end.

This code pushes asynchronous messages containing javascript to a generic
web page, and the web page evals the result.

This technique is amazingly powerful.

So now I only need one generic web page. Think of that.

Only one page is needed - forever.

All the generic pages does is:

loop:
   wait for a message containing Javascript
   eval the message

Beautiful

This is the easiest way to program a GUI I can conceive of.

You can download and run the examples from:

https://github.com/joearms/SEBG

You'll need something like Google chrome to run them.

Have fun

/Joe
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Masklinn
On 2011-02-12, at 12:33 , Joe Armstrong wrote:
>
> You'll need something like Google chrome to run them.
Warning: the status of the (currently broken [0]) WebSockets is unsure: Firefox and Opera already dropped it, it is unknown whether Chrome and Safari will keep it enabled by default. Chrome-wise, they've kept it for now but they plan on disabling it as soon as they hear of an exploit in the wild[1]

Also, it's going to be a complete and utter pain to debug: even the more modern JS debuggers of Firefox (via Firebug) and Webkit have insane amounts of trouble finding and debugging dynamically evaluated code.

[0] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
[1] http://codereview.chromium.org/5643005/
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Joe Armstrong-2
Which is why you should write correct code that does not need debugging.

The use of higher order functions that generate the code will make this
a lot easier.

The next stop is to generate the JS with HOFs and make sure the generators
are correct.

You don't want to write JS by hand - that's work - let a program do it for
you :-)

/Joe


On Sat, Feb 12, 2011 at 12:46 PM, Masklinn <[hidden email]> wrote:

> On 2011-02-12, at 12:33 , Joe Armstrong wrote:
> >
> > You'll need something like Google chrome to run them.
> Warning: the status of the (currently broken [0]) WebSockets is unsure:
> Firefox and Opera already dropped it, it is unknown whether Chrome and
> Safari will keep it enabled by default. Chrome-wise, they've kept it for now
> but they plan on disabling it as soon as they hear of an exploit in the
> wild[1]
>
> Also, it's going to be a complete and utter pain to debug: even the more
> modern JS debuggers of Firefox (via Firebug) and Webkit have insane amounts
> of trouble finding and debugging dynamically evaluated code.
>
> [0] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
> [1] http://codereview.chromium.org/5643005/
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Ulf Wiger
In reply to this post by Masklinn

Well, I read those links not as an indictment of websockets per se, but of the UPGRADE-based handshake. I think Joe is definitely on to something here, and this sort of setup fits Erlang beautifully.

Essentially, Joe may have found a way to dust off his ex11 idea[1], in a context where it is much more likely to succeed. ;-)

(But please, Joe, leave out the !! this time - one revolution at a time.)

BR,
Ulf W

[1]  http://ftp.sunet.se/pub/lang/erlang/workshop/2004/ex11.pdf

On 12 Feb 2011, at 12:46, Masklinn wrote:

> On 2011-02-12, at 12:33 , Joe Armstrong wrote:
>>
>> You'll need something like Google chrome to run them.
> Warning: the status of the (currently broken [0]) WebSockets is unsure: Firefox and Opera already dropped it, it is unknown whether Chrome and Safari will keep it enabled by default. Chrome-wise, they've kept it for now but they plan on disabling it as soon as they hear of an exploit in the wild[1]
>
> Also, it's going to be a complete and utter pain to debug: even the more modern JS debuggers of Firefox (via Firebug) and Webkit have insane amounts of trouble finding and debugging dynamically evaluated code.
>
> [0] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
> [1] http://codereview.chromium.org/5643005/
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com




________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Joe Armstrong-2
On Sat, Feb 12, 2011 at 1:15 PM, Ulf Wiger
<[hidden email]>wrote:

>
> Well, I read those links not as an indictment of websockets per se, but of
> the UPGRADE-based handshake. I think Joe is definitely on to something here,
> and this sort of setup fits Erlang beautifully.
>
> Essentially, Joe may have found a way to dust off his ex11 idea[1], in a
> context where it is much more likely to succeed. ;-)
>
> (But please, Joe, leave out the !! this time - one revolution at a time.)
>

!! would be evil in this context. As soon as you get outside erlang !! is
bad.
! is good because it creates no dependencies, the message either gets there
or
it does not. Code that can deal with this uncertainty will be good, other
code is
not.

It's actually pretty awe-inspiring to say

Pid ! button("click me") and see a button just appear in the browser

Great fun.

The great thing is that we can now abstract the interface

button("text") means return a thing that when evaluated makes a button
this code return Javascript, but it could equally well return xul, or html,
or llvm assembler
it doesn't matter - as long as the eval end knows how to eval it. So the top
level
code can be written entirely without knowledge of what's going on under the
covers

/Joe


/Joe



>
> BR,
> Ulf W
>
> [1]  http://ftp.sunet.se/pub/lang/erlang/workshop/2004/ex11.pdf
>
> On 12 Feb 2011, at 12:46, Masklinn wrote:
>
> > On 2011-02-12, at 12:33 , Joe Armstrong wrote:
> >>
> >> You'll need something like Google chrome to run them.
> > Warning: the status of the (currently broken [0]) WebSockets is unsure:
> Firefox and Opera already dropped it, it is unknown whether Chrome and
> Safari will keep it enabled by default. Chrome-wise, they've kept it for now
> but they plan on disabling it as soon as they hear of an exploit in the
> wild[1]
> >
> > Also, it's going to be a complete and utter pain to debug: even the more
> modern JS debuggers of Firefox (via Firebug) and Webkit have insane amounts
> of trouble finding and debugging dynamically evaluated code.
> >
> > [0] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
> > [1] http://codereview.chromium.org/5643005/
> > ________________________________________________________________
> > erlang-questions (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:[hidden email]
> >
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Jerome Martin-2
If only the browser could adopt for good a CONNECT-based handshake and
enable it by default, the world would be a better place to deploy web UIs
:-)

Because that remains the biggest issue for now, until I see this happening,
all that beauty might be lost :-(

On Sat, Feb 12, 2011 at 1:23 PM, Joe Armstrong <[hidden email]> wrote:

> On Sat, Feb 12, 2011 at 1:15 PM, Ulf Wiger
> <[hidden email]>wrote:
>
> >
> > Well, I read those links not as an indictment of websockets per se, but
> of
> > the UPGRADE-based handshake. I think Joe is definitely on to something
> here,
> > and this sort of setup fits Erlang beautifully.
> >
> > Essentially, Joe may have found a way to dust off his ex11 idea[1], in a
> > context where it is much more likely to succeed. ;-)
> >
> > (But please, Joe, leave out the !! this time - one revolution at a time.)
> >
>
> !! would be evil in this context. As soon as you get outside erlang !! is
> bad.
> ! is good because it creates no dependencies, the message either gets there
> or
> it does not. Code that can deal with this uncertainty will be good, other
> code is
> not.
>
> It's actually pretty awe-inspiring to say
>
> Pid ! button("click me") and see a button just appear in the browser
>
> Great fun.
>
> The great thing is that we can now abstract the interface
>
> button("text") means return a thing that when evaluated makes a button
> this code return Javascript, but it could equally well return xul, or html,
> or llvm assembler
> it doesn't matter - as long as the eval end knows how to eval it. So the
> top
> level
> code can be written entirely without knowledge of what's going on under the
> covers
>
> /Joe
>
>
> /Joe
>
>
>
> >
> > BR,
> > Ulf W
> >
> > [1]  http://ftp.sunet.se/pub/lang/erlang/workshop/2004/ex11.pdf
> >
> > On 12 Feb 2011, at 12:46, Masklinn wrote:
> >
> > > On 2011-02-12, at 12:33 , Joe Armstrong wrote:
> > >>
> > >> You'll need something like Google chrome to run them.
> > > Warning: the status of the (currently broken [0]) WebSockets is unsure:
> > Firefox and Opera already dropped it, it is unknown whether Chrome and
> > Safari will keep it enabled by default. Chrome-wise, they've kept it for
> now
> > but they plan on disabling it as soon as they hear of an exploit in the
> > wild[1]
> > >
> > > Also, it's going to be a complete and utter pain to debug: even the
> more
> > modern JS debuggers of Firefox (via Firebug) and Webkit have insane
> amounts
> > of trouble finding and debugging dynamically evaluated code.
> > >
> > > [0] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html
> > > [1] http://codereview.chromium.org/5643005/
> > > ________________________________________________________________
> > > erlang-questions (at) erlang.org mailing list.
> > > See http://www.erlang.org/faq.html
> > > To unsubscribe; mailto:[hidden email]
> > >
> >
> > Ulf Wiger, CTO, Erlang Solutions, Ltd.
> > http://erlang-solutions.com
> >
> >
> >
> >
>



--
Jérôme Martin
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Masklinn
In reply to this post by Ulf Wiger
On 2011-02-12, at 13:15 , Ulf Wiger wrote:
> Well, I read those links not as an indictment of websockets per se
Why would you? They're not, they're just warnings that websockets are getting disabled in browsers due to being currently broken, and that this kind of approach is therefore nice as a research toy but can not be considered for serious work at this point.

I don't believe I wrote anything against Joe's idea, I just forwarded short and mid-term issues with actually applying them outside of well-controlled demonstration environments.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Joe Armstrong-2
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

Of these four concurrency patterns three are crippled.

Instant messageing, for example,is trivial if you can push messages to a
client.

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.

/Joe



and

On Sat, Feb 12, 2011 at 1:49 PM, Masklinn <[hidden email]> wrote:

> On 2011-02-12, at 13:15 , Ulf Wiger wrote:
> > Well, I read those links not as an indictment of websockets per se
> Why would you? They're not, they're just warnings that websockets are
> getting disabled in browsers due to being currently broken, and that this
> kind of approach is therefore nice as a research toy but can not be
> considered for serious work at this point.
>
> I don't believe I wrote anything against Joe's idea, I just forwarded short
> and mid-term issues with actually applying them outside of well-controlled
> demonstration environments.
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

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

In fact, synchronous RPC-type calls are definitely frowned upon as they create terrible use experience (due to in-browser javascript being a purely 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?
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Marc Worrell
In reply to this post by Joe Armstrong-2
The funny thing is that zotonic and nitrogen already use this way of pushing dynamically generated JavaScript to the user agent. It works great.

Zotonic switches between a long polling comet connection and websockets depending on the capabilities of the browser.

By the way, websockets is not broken. Some proxies are broken.

- Marc


On 12 feb 2011, 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
>
> Of these four concurrency patterns three are crippled.
>
> Instant messageing, for example,is trivial if you can push messages to a
> client.
>
> 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.
>
> /Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Edmond Begumisa
In reply to this post by Joe Armstrong-2
On Sun, 13 Feb 2011 00:03:00 +1100, Joe Armstrong <[hidden email]> 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

These first 2 difficulties have been the biggest reason why I avoided  
writing web-apps that run in the browser for so long (I still avoid it).  
Just give me a socket and I'm happy.

When you're used to socket programming, where after a connection is made  
the line between who is the server and who is the client becomes blurry,  
it gets really hard to adapt to the idea that only the connectER can make  
requests to the connectEE (pardon my word invention.) Designs that you  
took for granted become next to impossible to implement.

> send an asynchronous message from the client to the server
>
> Of these four concurrency patterns three are crippled.
>
> Instant messageing, for example,is trivial if you can push messages to a
> client.
>
> Turning web sockets off for security reasons is stupid.
>

I agree 110%

With modern web-app development targeting browsers, a large amount of time  
is being spent finding work-arounds to enable programmers to do things  
that have been done in other environments. From bi-directional requests  
(websockets/comet/long-poll) to rich-UI (menus, drag and drop, etc.)

I think web-development is out-growing the technologies it's based on --  
web developers obviously want more. Attempts to stifle ideas like  
websockets that are trying to respond to the demand won't succeed in the  
long run.

In the meantime, runtime environments like Mozilla XULRunner and Adobe AIR  
that give developers a wider range of patterns to choose from (while  
giving them more responsibility for things like security) will gain more  
traction while browsers debate on whether to lift their constraints. Me  
thinks.

- Edmond -

> The solution is to sandbox the thing that receives the messages
> or if unsandboxed strongly authenticate the messages.
>
> /Joe
>
>
>
> and
>
> On Sat, Feb 12, 2011 at 1:49 PM, Masklinn <[hidden email]> wrote:
>
>> On 2011-02-12, at 13:15 , Ulf Wiger wrote:
>> > Well, I read those links not as an indictment of websockets per se
>> Why would you? They're not, they're just warnings that websockets are
>> getting disabled in browsers due to being currently broken, and that  
>> this
>> kind of approach is therefore nice as a research toy but can not be
>> considered for serious work at this point.
>>
>> I don't believe I wrote anything against Joe's idea, I just forwarded  
>> short
>> and mid-term issues with actually applying them outside of  
>> well-controlled
>> demonstration environments.


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Joe Armstrong-2
In reply to this post by Masklinn
On Sat, Feb 12, 2011 at 3:29 PM, Masklinn <[hidden email]> 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 - 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.


>
> In fact, synchronous RPC-type calls are definitely frowned upon as they
> create terrible use experience (due to in-browser javascript being a purely
> 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.

/Joe
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Masklinn
In reply to this post by Marc Worrell
On 2011-02-12, at 15:34 , Marc Worrell wrote:
>
> By the way, websockets is not broken. Some proxies are broken.
If these proxies being broken create a *security issue* with using websockets, then websockets themselves are broken.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Masklinn
In reply to this post by Joe Armstrong-2

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

> On Sat, Feb 12, 2011 at 3:29 PM, Masklinn <[hidden email]> 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.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Edmond Begumisa
On Sun, 13 Feb 2011 02:40:09 +1100, Masklinn <[hidden email]> wrote:

>
> On 2011-02-12, at 15:52 , Joe Armstrong wrote:
>
>> On Sat, Feb 12, 2011 at 3:29 PM, Masklinn <[hidden email]> 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.
>>>

Possibly you do have different definitions of "asynchronous message" :) I  
don't think client-side JavaScript actually push asynchronous messages  
over the wire, it just looks like this from the web-programmer's  
perspective. See below...

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

I have to disagree, I think the statement is perfectly correct. I believe  
what Joe meant here is:

* From the client, HTTP requests are not asynchronous because HTTP  
requests (GET/PUT/POST) by definition await a response from the server  
(200 OK, 404, etc.) This is not send and forget. It's send and wait. It's  
synchronous communication built on asynchronous communication.

* The browser hides the above fact from you (the web-developer) by  
enabling the single-threaded JavaScript environment to do other work  
in-between the request and the response even executing other requests (aka  
AJAX.) So your JavaScript is async but the actual messages (HTTP requests)  
are not.

* One workaround to send true async messages from the client to the server  
(which *I* know of and have used) is to multipart POST with a very large  
content-length header value and keep adding to the body, say lines of  
JSON, and allow the server to "eat" them as they come while not concluding  
the request for as long as possible. A kind long-poll in reverse. This is  
a pain for both client code and server code which is why I think Joe is  
correct when he says it's not "easy".

- Edmond -

>>>> 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.
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Joe Armstrong-2
In reply to this post by Masklinn
On Sat, Feb 12, 2011 at 4:40 PM, Masklinn <[hidden email]> wrote:

>
> On 2011-02-12, at 15:52 , Joe Armstrong wrote:
>
> > On Sat, Feb 12, 2011 at 3:29 PM, Masklinn <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Jerome Martin
In reply to this post by Masklinn
On Sat, Feb 12, 2011 at 4:34 PM, Masklinn <[hidden email]> wrote:

> On 2011-02-12, at 15:34 , Marc Worrell wrote:
> >
> > By the way, websockets is not broken. Some proxies are broken.
> If these proxies being broken create a *security issue* with using
> websockets, then websockets themselves are broken.
>

This must be one of the most nonsensical sentence I have read since a long
time from someone supposedly mastering basic logic. Nice one.


--
Jérôme Martin
Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Edmond Begumisa
On Sun, 13 Feb 2011 06:10:55 +1100, Jerome Martin  
<[hidden email]> wrote:

> On Sat, Feb 12, 2011 at 4:34 PM, Masklinn <[hidden email]> wrote:
>
>> On 2011-02-12, at 15:34 , Marc Worrell wrote:
>> >
>> > By the way, websockets is not broken. Some proxies are broken.
>> If these proxies being broken create a *security issue* with using
>> websockets, then websockets themselves are broken.
>>
>
> This must be one of the most nonsensical sentence I have read since a  
> long
> time from someone supposedly mastering basic logic. Nice one.
>
>

Sounded like circular logic, but I _kind of_ see what he was trying to say  
;)

Browsers, much like OSs, are in the unfortunate position of having to be  
careful what they introduce coz of the impact on other-people's faulty  
code. Too careful in the websockets case. Web developers have been  
suffering from the uni-directional issue for too long. It's not a minor  
limitation, it's major. Broken proxies just need to be fixed and not pass  
the blame.
       
I've waited in vain for the Mozilla Framework (and hence Firefox) to  
support websockets. The debate reminds me of Linus rather rudely  
complaining about the undue status given to fixing "security" bugs over  
"normal" bugs...

http://thread.gmane.org/gmane.linux.kernel/701694/focus=706950

The solution might be for web-developers to move away from browsers and  
handle their own security.

- Edmond -
       
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Alain O'Dea
In reply to this post by Masklinn
On 2011-02-12, at 12:04, Masklinn <[hidden email]> wrote:

> On 2011-02-12, at 15:34 , Marc Worrell wrote:
>>
>> By the way, websockets is not broken. Some proxies are broken.
> If these proxies being broken create a *security issue* with using websockets, then websockets themselves are broken.

To clarify for the unwary:

No exploit lab or otherwise exists that functions in the context of the whole websockets stack from Chrome or Firefox.  The vulnerability is identified on one component in isolation where it never would be in any real system.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Two beautiful programs - or web programming made easy

Florian Weimer
In reply to this post by Joe Armstrong-2
* Joe Armstrong:

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

XMLHttpRequest has an asynchronous option.

And you can get emulate a single full-duplex connection using two
half-duplex ones, so Websockets is just an optimization, and likely
not even a very much needed one.  The barrier right now seems to be
the BSD sockets API and kernel state management, and you still have
that with Websockets.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

12345