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.
This technology is getting phased out and mostly only works with images.
Our app does something like this by loading an image with an xhr then immediately requesting the next image when the previous one finishes
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?
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.
I have often asked in interviews if my job title could be Web Master for nostlolgia.
I never get that title :(
C was used, but Perl quickly became more popular.
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.
That's server side C code speaking HTTP using the common gateway interface protocol.
Usually http video and audio streaming uses chunked encoding.
I wonder if this can be used to stream regular GIFs, so that you don't have to wait for the whole thing to load before seeing the animation.
I'm currently working on a project focusing on GIFs (https://www.gifsonic.com), I'll definitely study this to see if it's possible.
Sometimes it gets stuck and doesn't show the whole gif but I just assume that's my/the website's connection.
I wonder if this technique can optimize preloading.
For instance, we could send out only 1/2 of the frames (of course, with twice the delay to keep the same animation speed), then load the rest as it's available.
I have no idea what I'm talking about yet, but there seem to be something here.
- First load first frame on lowres (may be so lo that is blurred)
- Then add a small rotating loading icon on top of image, possibly with a notation that is a GIF
- Then load first frame completely at correct resolution
- Then load all the other frames in the background, only showing me the first frame still
- When all frames are completely loaded, remove loading rotating icon and run the GIF normally.
If the browser only keeps compressed frames, 16 GB will last for more than a year.
- In Chrome it shows nothing (looks like it waits for end of stream)
- In Safari it shows only the first frame
- In Firefox it works (shows animated clock)
Branch with chunked encoding: https://github.com/kolen/time.gif/tree/chunked-encoding
One can use automatically generated gifs to add things like countdown timers based on the opening time of the email. (i.e. loading time of the image) See for example this post: https://litmus.com/community/learning/27-how-to-add-a-countd...
I would be a bit hesitant (teaching-wise), to talk about any function of the type IO () -> IO Char -> (Frame -> IO ()) -> IO ()
Although, not to be a spoil sport, it seems like a fun thing to do over a long weekend.
Exercises in German here: https://github.com/def-/gifstream/blob/master/Aufgabe.pdf
imShow :: [[Int]] -> IO ()
playSound [Int] -> IO ()
It might be more convenient to download the annual winning entry tarball.
Alternatively, try the index for all of the winning entry files.
edit: By the way, if you download 2013.tar.bz2, I highly recommend checking out the cable3, which implements an entire IBM PC capable of running Windows 3.0 in only 4043 bytes (8086 nibbles).
People interested in that emulator may also want to know that the non-obfuscated version (still only 760 physical lines of C, though that's partly achieved by putting opcode information in the BIOS ROM) has moved to GitHub:
$ mpv --cache=no https://hookrace.net/time.gif
So if gif 2 is embedded in 100 sites will it bring my server down since children are not closing connections?
Edit: I have now added some cache-control directives, maybe they help
There's probably a cheap optimization in there somewhere. Diffing frames on each tick, but for that size it probably doesn't matter. Thanks for the link to GifStream!
The first time that I saw an accurate countdown ticking away in an email, it surprised the heck out of me.
This seems rather difficult. These are dynamically generated. There are 246060=86400 possible slides, but at download time, we have to find the correct starting point. Did I get that right?
You may optimize it by sending diffed frames (IIRC the gif format allows one to only update the pixels that change from one frame to the next). You could even pre-generate both sets of images (full frame and diff) and use the script to send the right frame at the right time.
Source code for this program is very small, despite it even encodes gif on its own and does http on its own, without using external libraries.
"[It] works by dynamically generating each frame of the GIF and slowly feeding them over the HTTP connection."
So there is nothing (AFAICT) new or interesting going on here. It's just an animation generated by the server in real time that happens to be formatted as a gif. It's no different from what many low-end web-enabled security cameras do.
Though I'm not sure why you even care what HN likes. It certainly isn't measured in units of innovation, as you seem to think it should.
"This is absolutely awesome."
I'm just trying to understand why people think it's "absolutely awesome." It seems, at best, mildly interesting to me.
Let's turn it around. Why do you think it's so important that we understand how unimpressed and uninterested you are?
This is a simple, accessible project that people think is fun. They upvoted it.
for me it has no real application that I can think of, it consume lot of bandwidth and processing even for small size gif.
good knowledge for developer, I certainly cannot even think in that line. But no use of it in current form.