EditStream

For those using a RSS reader, subscribe here: rss.xml

To be honest, after all these years of computers existing, there are enough text editors that are stable enough to work with and be used for a long time. Text editors have stood the test of time, most we do on personal computers is inputting text. So we better have an efficient way of transporting this data. Infact we do. For non-moving imagery we mostly figured it out. Large blobs of texts are saved as text, not as tons of screenshots (disregarding the unintentional screenshotting of everything among the less technically-aware). The moving imagery gets more interesting. It seems that saving content rendered is the chosen default. Which is a sensible default, it ensures it looks the same on each screen. There is no heavy reconstruction logic involved. If you would put it on a scale along with the other techniques I am about to mention, it is the most naive/hassle-free solution.

Improvements

The reason why I argue this will be reworked is because it is really, really data heavy. Why do we love SVG so much compared regular images? Besides always looking crisp, it takes up constant space in respect to scaled version of the images (Also easier to edit, will touch on that later). And as constant space complexity is better then squared, it takes up less space. It also makes much more sense if what you want to capture was made with vector art. It would be a non-logical idea to save random images all as svg. The point is that we want fileformats resembling the creation.

Purpose

This is where file-formats are about: capturing the data needed to reconstruct the original entity with as much resemblence to the original as possible. Capturing it as close to the original allows intuitive editing and handling of the file. So when some script-kiddie on the internet is bashing their keyboard teaching programming 101, what would make more sense to save? Which one would it be?

  • A: his current edit buffer and all changes he makes to it
  • B: capture every pixel hundreds of times per second on their constantly changing 8K monitor

I would argue that it would be both much more space efficient and logical to go for option A. Just like with imagery, editstream will be the SVG for video of text-edit-sessions. But wait I here you say, how would you capture the rich configurations of the editors? Well, this is the best part of all: the format will see no difference in who typed it, so the reconstruction can be done with either your prefered editor config or with that of the original author. It is all config as meta-data.

Implementation

Now for actually implementing this seemingly superior format for certain usecases; There are already similar projects that can be leveraged for this: pair-programming, code-sharing, teletyping you name it. Take that idea and stream it to a file first. That is all.

It is already out there, you know

So after drafting I found out it already exists, and it is called asciinema.