I've just written a little more about wom on this page. I am now happy with the abstractions. I've also been thinking about a little language to start processes and connect files together. That way, a spreadsheet program can connect to a charting program, and the chart can update as soon as a selection is made. More on that soon!
I cleaned the files exposed by a process down to: `ctl`, `wctl` and `label`. The ctl files (ctl and wctl) take in commands and act as pipes: you write to it, the text is consumed. ctl are commands for the process. wctl takes commands to manage the window attached to the process. At first I had a `rect` file, changing the file would update the window's coordinates. But using a ctl file lets me do validation, check ranges etc. For example, to move a window to position 10x10, we can do `fs.write('/proc/pid/wctl', 'size 10 10')`. I've also added a `/opt/start` file where we can list what goes to the global right-click menu
I got a new coffee machine, and it's really good! On wom, I realized that I was conflating commands and state when it comes to IPC. For example, a process folder would expose an observable `dirty` file. Removing its content would trigger a save and update the UI of a window to remove the '*'' next to the name. But what if the save operation fails? What if the program was opened without a path? I could work around that by introducing a little state machine in the `dirty` file: '!' could mean "i request a save" and "*" could mean the file is dirty. But if each file in the process have to expose a mini state machine, the complexity skyrockets. Instead, I went down the Plan9 route: process that will take commands expose a `ctl` file. That file acts as a pipe: what you write in it gets consumed. That's how the outside world communicates with the process. Write `save` in it and the process will trigger a save. Since the content of the observable gets emptied after each message, we can send the same command twice. When we read that file, we see the content of the internal states of the process with key values. I could do that by 1/ creating a ctl file and saving its original data observable's set function and 2/ replacing the file's data set by a new one that just checks the command and take actions 3/ update the original data when any state change.
I did some preliminary work on the directory structure of the filesystem for wom. The OS is single user, which simplifies things a lot. I'm using /tmp to store current Prompt windows return values. Since a file is an observable I can just listen to any changes to it and trigger a callback accordingly. I've added a Confirm program too, as well as a `dirty` file within a proc/{id} directory. When attempting to close a process that has a non-empty dirty file, a Confirm window appears to ask for confirmation. The fact that `dirty` is a file allows programs from the outside to trigger a save as well. For now, that's how I plan to manage IPC.
I'm setting up this new journal. My attention's been scattered a bit and I'm not sure where to write anymore, so here's the place! I've moved contents I had from other places to m15o.net. I've added a context menu to wom, and simplifying the folder structure. It's going to be a strictly single-user operating system. It's also now possible drag/drop files to Dir from your host computer.