[erlang-questions] Two beautiful programs - or web programming made easy
Sat Feb 12 18:02:23 CET 2011
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
>>>> 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
>>> 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
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
>> this that
>> why I said "easily" it can be done with horrible work arounds like comet
> 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
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
in-between the request and the response even executing other requests (aka
* 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
>>> (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
> 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/
More information about the erlang-questions