[jauntywundrkind]

I have a js proxy project that auto-persists changes out live, as you change the object, rathre like this. I really need to get back to it.

The advantage of being able to see state easily is incredible. It's so scriptable. I only demo'ed it for myself, but I've also run a git-auto-commit program on the data as it changes over time, which is much more useful commits to look at over time than seeing data in a huge JSON file change.

I really really hope we can start using the hierarchical file system to hold data. For transport, its convenient to have data glommed together, but I think we're really missing out on end user programming and malleable systems by having these rich data formats everywhere and keeping the filesystem dumb.

[QuantumNomad_]

If I understand correctly:

- OP project manages contents of multiple files as a single JSON with the intention of tracking that one single file in git, and splits it into the original files when you apply it

- Your tool sounds like it can do the same thing, split one JSON file into multiple files, but it’s geared for use the other way around, to track in git as separate files the pieces that make up the total JSON as a.

Both tools can probably be used for the same, it’s up to the user to decide if the combined file is the result and the split files are for git or the other way around.

And fwiw, I agree with you that keeping the split up thing in git is more helpful for reading diffs than a single massive JSON file. I have some scripts in one of my projects too, that takes fragments split across multiple files which are separately tracked, and combine those into single JSON files when I use them.

[alurm]

Well, if you're generating JSON with Nix, you don't have to put everything inside of one file. It would be a better idea to split it up into multiple. You can also use builtins.readFile for reading config files which don't have to be generated in a complex manner. It's up to you to choose, I just kept everything inside of one file since it makes for a simpler example.

Edit: I have updated the documentation to mention this explicitly, thanks!

[porridgeraisin]

> file system to hold data

My bespoke clipboard manager also uses the filesystem as the primary data structure.

h/$serial_number/$mime_type/{data, index}

H for history. data has the actual paste data. index has metadata useful for search - window name, day name, I also include wifi network so I can find clipboard history in terms of place, if I remember it that way. It also includes a copy of the data file if it's a text paste. You can include anything really it's fairly flexible. You can write whatever executable you want to the *-posthook file and they are all executed with argv having the path to the history entry directory. You can then modify the index as you please.

I have a few frontends to actually use this clipboard history as well. One is a gtk3 frontend searchbar + list below. Another is a cli fzf based thing.

Since the data structure is just the filesystem it's really composable and amazing.

Various things like blacklisting windows, "pausing" clipboard history, etc are all just files as well.

If you create a pause file it will pause (there's an if test -f pause check). You can add a grep -E pattern to the blacklist file and it won't paste from those window names.

Unlimited history since I don't care about space. But it does support wrapping around after N items.

Sync with phones is one thing i have to figure out...syncing across my different computers is dead easy of course.

[alurm]

Yeah, in general (a bit of a tangent), ideas from Plan 9 are really powerful. For example, the Acme text editor exposes it's API as a file system (it's represented via Unix sockets in plan9port, but FUSE is available as well there). It's easy to write scripts to manipulate the editor, and quite fun.

[jauntywundrkind]

I 100% have been inspired plan9, not actually a tangent at all!

I never spent much time in Acme. I did use wmii as a daily driver window manager for a number of years, which was also 9p based! I wasn't great at scripting it, and the docs have always been basically non-existent for it's 9p interfaces... but I did poke around and look at things, which was super easy to do because it was just a filesystem! I did find this short example of some wmii examples, inside a Chicken Scheme 9p write-up, which is lovely to see online: https://wiki.call-cc.org/eggref/5/9p#utility-procedures

It's a fine distinction, but I do like json2dir and my own work a bit more than 9p because with apps that expose 9p, if the app goes away, so does the filesystem! 9p is an interface to talk to some process state. But if you just keep state on the regular filesystem, it will stick around & persist beyond the life of the process. The downside is your app needs to watch for that state changing, needs to be able to reconcile changes as they happen. On the upside though, now you can use a lot of great filesystem utilities: for example btrfs or zfs snapshots or incremental-backups are going to work as usual!

Being able to easily script your world is-I think- a missing key to unlocking personal computing. Different technologies discussed, but another serendipitous thread on personal computing from today: https://news.ycombinator.com/item?id=44837783