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

Sun Feb 13 19:36:26 CET 2011

Yes, since Joe's WebSocket blog
post<http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html>
I
think many people have had that idea in the back of their minds, floating
around, waiting for some signal that WebSocket was out to the general public
for good and could be considered as a usable in real life. Unfortunately, as
we all realize, it is not the case yet, and most frustrating, probably for
the wrong reasons :-(

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

> +1
>
> The thread went off topic. Joe e-mailed me with an idea like this many
> months ago off-list. I liked it then and I like it now. I even borrowed
> little bits of it in my current XULRunner projects (XUL has some limitations
> preventing the exact model).
>
> In fact, I've been thinking of some ways adding some templating to his
> code. So you can send "groups of widgets" down to the browser to display. It
> also got me thinking about some sort of flow language that can be used for
> people that don't know Erlang so they can easily string screens and widgets
> together in a flow chart manner.
>
> - Edmond -
>
>
>
> On Mon, 14 Feb 2011 04:08:05 +1100, Jerome Martin <tramjoe.merin@REDACTED>
> wrote:
>
>  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
>>>
>>>
>>>
>>
>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

-- 
Jérôme Martin