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

[Edmond Begumisa]

On Sun, 13 Feb 2011 00:03:00 +1100, Joe Armstrong <erlang@REDACTED> 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 <masklinn@REDACTED> 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/