No-JS web IRC client that uses forms and a persistent HTTP connection
11 points by runxiyu
11 points by runxiyu
I did something similar a while ago for a yearly stream I help organize, where the chat is on IRC but I wanted to add a "danmaku" (where the chat messages are overlaid on top of the video and fly from left to right when they arrive) option to the stream website, which meant pumping IRC messages to each channel. At first I thought I'd have to use websockets or SSE, but good ol' chunked transfer encoding did the trick.
On the server side we send a response without Content-Length and with Transfer-Encoding: chunked and forward the PRIVMSG as a chunk to each socket, and on the client side we get a response.body.getReader() and on each message we create an HTML element with a CSS animation that makes it scroll across the screen and spawn a timeout to delete it after a couple seconds. Not very fancy but very effective!
It’s no longer online, but I similarly made a snake game that used chunked transfer encoding, forms, and CSS. Unfortunately, it didn’t work in Netsurf, Dillo, w3m, or Lynx, which made me sad.
Hmm, although the filesystem-ID-persistence-cookie and the CGI perl script and C communications seem very fragile here, I could imagine a more usable versions of this for FastCGI or just serving HTTP directly, while retaining its (cursed) persistent HTTP poll.
Meta: For the use of the art tag, cf. in particular, stories tagged with both art and satire.
I initially wrote this >20 years ago(!). There’s some cursed choices in there like avoiding IO::Socket because it made the memory usage of each perl process lower. Definitely these-days using anything other than CGI would be a better choice, although the fact this still works many years later maybe says something about the simplicity of CGI. (The recording isn't great but I spoke about this: https://www.youtube.com/watch?v=yb5yu7Q6JQ8 -- "David (“dg”) has been on IRC for many years, he was the author of CGI:IRC, but suggests you use something else now.")
Pretty cool that you replied. Much have changed since the CGI times, right? Thanks for this. It served pretty much as THE proof that everything would move to the web.
That said, it feels great writing this very comment using and html form with a full page refresh.
Hi - thanks for chiming in here. Were there any interesting issues getting the html page to update without js? (I am assuming you are using chunked transfers)
This was in the days of HTTP/1.1 (at best), chunked encoding doesn't give you much, the connection is going to stay open anyway, all chunked encoding does is let you reuse a connection which you don't know the content-length of (well, and support trailers, but hardly anyone supports that). The main trick it does is send a HTML comment every so often to pad things. At the time the biggest issues were things between the perl program and the browser that caused buffering, Apache's mod_gzip being a common example.