2023.11.24 Fri 13:54 File system based program interface Oh boy I'm nearly done with my web CLI client. I can navigate Gopher Holes by URI or links, display parsed pages and it's possible now to extend it with support for Gemini protocol. I sure nothing bad will happen and I don't get sudden urge to rethink my entire programming style and start project from scratch ... FILE SYSTEM BASED PROGRAM INTERFACE! \('O' )/ $ cd ~/repo/my_epic_project_that_i_spent_many_hours_on/ $ rm -rf * $ ls $ I regret nothing :> After learning Acme in first half of 2020 I was fascinated with how easily it can be extended using any programming and scripting language just because it was exposed as file tree representing program state. Later I saw similar idea in Suckless ii IRC client [1]. Since then I always wanted to try this myself. The new version of my CLI client already works to some extend. I will use it to explain this concept. $ tree ~/yupa/ /Users/irek/yupa/ |-- 0 | |-- fmt | |-- raw | `-- uri |-- 1 # empty dir |-- 2 | |-- fmt | |-- raw | `-- uri `-- 3 # empty dir When program runs it creates or reuses root directory (~/yupa in this case) that contains sub directories being web browser tabs. Each tab contains 3 files. The most important file is "uri". When you insert valid URI to this file then program will make and request to it and write raw server response to "raw" file and if this was file that should be formatted like text/gemini or Gopher index file then it also formats server output to "fmt" file. Adding new sub directory equals to opening new tab. Removing directory is closing tab. This is the basic idea so far. Why do it that way? By exposing entire program to file system you can now easily integrate all programs that works on files. This is the same as with regular CLI that uses text as interface and by that it's possible to integrate with it all programs that works on text. You can also easilly develop any client on top of this. Anyway, the plan is to try this approach. As a result I should have 2 separate programs: the daemon that manages file tree and client that uses it. I should come up with a new idea for the project name. One for daemon and second for CLI client. [1] https://tools.suckless.org/ii/