Excellent article, especially the detail to which it goes into how TRON handles files. This is pretty cool:
BTRON’s core idea was that the user-visible primitive on a desktop computer shouldn’t be a file or the application, but the typed document part. In other words, a block of content with a stable identity and a declared type. Parts can contain other parts, and the same mechanisms that embed a figure in a report can also embed a report in a workspace, meaning that there was no special case for a top-level file.
This model could be found across the interface as well, and you can browse a container in 1B/V3 and see each entry carries its type in parentheses after the name. For example, a document called 中国・韓国料理ガイド（図形）, meaning “Chinese and Korean Cuisine Guide (Graphics)”, describes this file as an image. In comparison, DOS would have given you an extension.
…but I’m curious as to how BTRON handled multiple file versions (backups, revisions, etc) if there’s not a top-level file.
Imagine there was no Explorer or Finder, and the only way you accessed files was through the apps that use them.
There’s still bytes on disk, but they are accessed as documents not files.
Which is how most Android and pretty much all iOS apps do it.
I don’t know how BTRON did it, but you could definitely do revision history with copy-on-write.
I recall Apple having ideas about a filesystem that didn’t have filenames, but instead had keywords that described the files. I looked for it but the only thing I could find was the unreleased filesystem object oriented filesystem demoed in 1994 with Copland, but I could’ve sworn they had something similar but more recent.
for those wondering and wont read (it is an interesting read)… the us government ocked it because they felt the japanese goverent had too much control of the OS.
