Hacker News Reader

Comment by koliber | Hacker News Reader

In 1994 I was in high school, and there were no animated GIFs. One way you could make images move in the web browser was to use a mechanism similar to this.

I wrote a C program which would load 6 frames of a smiley face animation and would feed them sequentially, in an endless loop, to anyone who requested the image. Mosaic was happy to animate them.

I get called in to the web mistress's office. The web server is down. We had a donated Silicon Graphics Origin server, if my memory serves me correctly. This was a beefy machine.

The cgi-bin C program would load 6 images, as fast as it possibly could, and dump them into a network socket. It would not throttle. It would not check if the client disconnected. It had one job. It did it efficiently, and ruthlessly.

Poor server.

View on HN

I expect that you were using this weird corner of the HTTP spec that is X-Mixed-replace[1]; where the server can keep feeding responses for the same request and the browser is supposed to replace the element with the new-one. A lot of IP cameras are using this to stream JPEG to the browser.

This technology is getting phased out and mostly only works with images.

[1]: https://en.wikipedia.org/wiki/MIME#Mixed-Replace

bugzilla still uses it to show the "Please wait while your bugs are retrieved." page while executing a search to then replace the page with the results.

What's the replacement? What's the way to live stream video without javascript?

You can stream video with the HTML5 <video> tag.

Video tag pointing to an MP4 will use byte range requests in chrome, which is pseudo streaming. For real streaming look into something like rtmp or hls, which does require js in some browsers. The main difference is one can handle live feeds the other cannot to my knowledge. Also real streaming has adaptive bitrate (switch to lower quality to avoid stuttering and buffering). The distinction between streaming and pseudo streaming is blurry. My litmus test is it can it handle live feeds? Html5 video tag cannot without hacks, per my understanding

Our app does something like this by loading an image with an xhr then immediately requesting the next image when the previous one finishes

Multipart+JPEG is easily 5x more expensive than MP4 in terms of bandwidth. All new IP cameras come with MP4 as a replacement. Steaming can be done in various ways, usually with the help of some JavaScript + video tag.

This sounds super interesting; a bunch of questions:

Did you just sent multiple images concatenated into the output stream, including file headers? And Mosaic would actually replace the first image with the second and so on? Was the CGI script referenced in an <img> tag?

What image format was this?

Probably jpgs. This used to be how all streaming “webcams” worked until not that long ago

I don't remember the details.

I think they were GIFs. From what I recall, I read the entire images as they were on disk and pushed them down the stream.

Someone mentioned https://en.wikipedia.org/wiki/MIME#Mixed-Replace and that is ringing a tiny bell.

Honestly, it was 23 years ago and I forgot the exact details. I still remember the meeting though. The feeling of dread, excitement, and ridiculousness of knocking out such a powerful machine (at the time) in order to server animated smiley faces.

Nowadays, I knock out powerful machines doing slightly more useful things.

Oh the 90s...

I have often asked in interviews if my job title could be Web Master for nostlolgia.

I never get that title :(

This was what we did before gifs. Then gifs came along and we stopped. Funny to see it again... as an innovation! Remember history, because it repeats.

Oh yes, server push animation. I checked it out a few years ago, and it seems to still work in Mobile Safari:

http://pronoiac.org/misc/2009/10/server-push-animation/

how can such an old browser run a C program embedded within it? Can someone elaborate how this could have been done

NCSA httpd introduced the Common Gateway Interface which allows you to execute any binary, and whatever it puts on stdout is sent as the reply. Back then it was typically a Perl script or a compiled C binary.

https://en.m.wikipedia.org/wiki/Common_Gateway_Interface

My company makes a DAS(distributed Antenna System) product with an embedded web interface. All of our web sites have C/C++ cgi back ends. There are more makefiles in the Web folder than the whole rest of system. It is quite mind boggling. But the engineer that has control over this area is stuck in the 90s.

My main objection to such systems is security. It is difficult enough to take care of it in modern frameworks, but in C?

Pretty sure the C was on the server in this instance.

Yes CGI was just an API between the web server and a an executable to handle the call, really no different than how Apache talks with mod-PHP.

C was used, but Perl quickly became more popular.

Never saw /cgi-bin/ in a form URL? Or the occasional xycorp_isapi.dll? :)

Found the old guy :). Back then it was quasi-normal to just write your own HTTP server. A TCP socket that just slapped some headers on whatever it was reading from disk. Now everything is so complex...

I remember using server push, and the CGI interface was a hell of a lot simpler than the 8000 levels of abstraction my Typescript Angular apps going through before they hit the wire.

The worst part is that the majority of the added complexity is useless. Instead of replacing the bad parts of HTTP, HTML, JS, and CSS we just build more shit on top of it. This requires more hacks and just up the complexity level even more.

“The cgi-bin C program”

That's server side C code speaking HTTP using the common gateway interface protocol.

Reply on news.ycombinator.com