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

Sun Feb 13 18:08:05 CET 2011

Just my 2cents....
(warning, if you are prompt to be upset by dramatically different opinion
than your, please do not read the following)

On a totally (not so ?) subjective mode:
  - (my) Taste tells me Joe's code is beautiful.
  - If such beautiful code is conceptually possible, it seems the right
thing to do (remember, we are in subjective mode)
  - Preventing that beauty from happening (not supporting features enabling
it), or claiming it is not necessary (presenting ugly code that does not
feel right and claiming it is the same) seems like the worst thing to do,
even if alternatives can be motivated (security reasons, etc.).

Now, on a purely pragmatic mode:
 - My experience (dealing with computer code since 20 years) tells me that
my taste buds are not that subjective, and are more than often right:
usually, I find (or someone else does) later a technical demonstration that
intuition and taste got it right.
 - It is rare enough to trigger taste to a level that we can call beautiful,
so definitely Joe must be on to something there :)

To everyone with rotten taste buds (serious mode but I won't argue or defend
my views):
  - No, taste is not that subjective. I do think some people have bad taste
and some other good taste, in an absolute sense. Matters of taste are a tale
imagined not to upset anyone.
  - Can't you see that there is something beyond technical arguments thee
that yells "this is the right way to do it" ? I mean, really ?

On Sun, Feb 13, 2011 at 3:33 PM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

> On Sun, 13 Feb 2011 21:18:53 +1100, Florian Weimer <fw@REDACTED>
> wrote:
>
>  * 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.
>>
>>
> There seems to be some confusion. Forgive me, but aren't asynchronous HTTP
> requests very different from asynchronous messages? Isn't the "asynchronous"
> in XMLHttpRequest talking about the scripting environment in relation to
> thread-blocking and not the messages themselves?
>
> Asynchronous XMLHttpRequest just means that you can do something else while
> you wait for the reply, but a failed reply is still a fault so the message
> depends on the reply (or the reply can be viewed as part of the message).
> XMLHttpRequest is just a workaround to allow single-threaded scripting
> environments not to block so they can handle multiple requests without
> introducing multi-threading, but you *always* have to deal with the reply.
> My understanding is XMLHttpRequest in whatever mode does not magically turn
> HTTP requests into asynchronous *messages*.
>
> What is an "asynchronous message" anyway?
>
> AFAIK, it means send and forget. For Erlang's case this is...
>
> Recipient ! Message
>
> From here on, you are free to go about your business and not have to deal
> with any response. The recipient need not send you back any acknowledgement
> to make the message "final". The message is thus asynchronous because you
> send and forget.
>
> Compare this with HTTP...
>
> PUT /foo?message=Message HTTP/1.1
>
> From here, the message is not complete until the server responds...
>
> HTTP/1.1 201 Created [or 504 or whatever]
>
> For XMLHttpRequest in synchronous mode, the scripting environment's thread
> blocks until the message is concluded. For XMLHttpRequest in asynchronous
> mode, the scripting environment's thread churns on but the message is still
> not concluded until the reply arrives. The message is thus synchronous
> either way because you don't send and forget, you have to write code to deal
> with the reply.
>
> Correct me if I'm wrong, but if you send and have to deal with a response
> from the recipient, regardless of whether you can do something else as you
> await the response, the message itself is not asynchronous. An HTTP message
> consists of 1) send and 2) get reply, so is synchronous by definition.
> XMLHttpRequest can't erase this, but it can allow you to workaround it.
>
> The workaround is an ugly hack that involves packing many "sub" messages
> into the request and waiting forever for a reply while taking advantage of
> non-thread-blocking in the scripting environment (i.e. comet/long-poll)...
>
> So, to send truly asynchronous *messages* from server to client, the client
> would...
>
>   GET /foo/comet_interface HTTP/1.1
>
> Server responds, streaming back a reply while not concluding the reply for
> as long as it can hold the connection open. It first sends headers, then
> keeps appending the asynchronous messages...
>
>   HTTP/1.1 200 OK
>   ..Headers..
>   InnerMessage1
>   InnerMessage2
>   ..
>   InnerMessageN
>
> Client then uses it's non-thread-blocking XMLHttpRequest to read the inner
> messages as they arrive and tries not to close the connection. The client
> has to know how to chop them up and the server might need to keep sending a
> regular special heartbeat sequence when idle to keep the connection open. So
> the "outer" HTTP GET message itself is synchronous (send and wait for
> reply), but the "inner" messages packed inside are asynchronous (send and
> forget). This is ugly, but web-developers have made it work out of
> desperation.
>
> To send truly asynchronous messages from client to server is even tricker
> and uglier. It might looks something like...
>
>  POST /foo/multipart_interface HTTP/1.1
>
>  Content-type: multipart/form-data, boundary=AaB03x
>
>  --AaB03x
>  content-disposition: form-data; name="message1"
>
>  InnerMessage1
>  --AaB03x
>  content-disposition: form-data; name="message2"
>
>  InnerMessage2
>  --AaB03x
>
>  ...
>
>  content-disposition: form-data; name="messageN"
>
>  InnerMessageN
>  --AaB03x--
>
> Again, the "outer" HTTP POST message is synchronous (send and wait for
> reply), but the "inner" messages are asynchronous (send and forget). This
> hackery is harder than it needs to be.
>
>
>  And you can get emulate a single full-duplex connection using two
>> half-duplex ones,
>>
>
> Synchronous full-duplex messages are still synchronous messages. Both sides
> still expect replies from the other, they can just do so at the same time.
> What you can do, as illustrated above, is simulate asynchronous messages
> with synchronous HTTP. And it's complete pain in the arse.
>
>
>  so Websockets is just an optimization,
>>
>
> I disagree. WebSockets allow you to send asynchronous full-duplex messages
> without the hackery of comet/long-polling. Just look at how clean Joe's code
> is. A websocket-less version would be possible, but uglier.
>
>
>  and likely not even a very much needed one.
>>
>
> IMO, the very fact that web-developers have frequently used various
> workarounds proves that it's needed. There is a disconnect between what web
> developers want and what the infrastructure currently provides. Websockets
> tries to address some of that.
>
> Personally, I think it's *very* much needed because it opens up the
> possibilities of what you can do with the web-browser as a client. The web
> browser starts to look more like a ordinary TCP client. You can do more of
> the things that are easy with plain sockets which have always frustrated me
> with browsers. Just look at Joe's idea. Those sorts of ideas don't
> immediately spring to mind when you're stuck in the mindset of
> uni-directional synchronous messages.
>
> - Edmond -
>
>
>  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:erlang-questions-unsubscribe@REDACTED
>>
>>
>
> --
> 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:erlang-questions-unsubscribe@REDACTED
>
>

-- 
Jérôme Martin