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

[Edmond Begumisa]

On Sun, 13 Feb 2011 02:40:09 +1100, 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.
>>>

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:erlang-questions-unsubscribe@REDACTED
>


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