Comment by moron4hire
12 hours ago
This is... I don't know. I don't get why I would care to sling SQL over a file system versus a network socket.
I mean, Postgres could offer an SSH interface as a dumb pipe to psql to just have you push text SQL queries in your application. But it doesn't, it offers a binary protocol over a network socket. All the database engines have had the same decision point and have basically gone down the same path of implementing a wire protocol over a persistent socket connection.
So yeah, I don't get what doing things this way would give me as either a service provider or a service consumer. It looks like video game achievements for OS development nerds, "unlocked 'everything is a file'." But it doesn't look like it actually enables anything meaningful.
How would you connect to Postgres in 4 lines of shell normally? How would you do it for a rest api? How about any other systems?
For Plan 9, it's all the same, all using the same interfaces, with little library glue.
Opening a window, and running a command in it? Similar interfaces. Adding LSP to your editor? Got it, you mount it and write to the files.
Universal shared conventions are powerful.
But if it requires understanding of a data protocol, it doesn't really matter if it's over the file system or a socket or flock of coked-up carrier pigeons. You still need to write custom user space code somewhere. Exposing it over the file system doesn't magically make composable applications, it just shuffles the code around a bit.
In other words, the transport protocol is just not the hard part of anything.
It's not hard, but it's sure a huge portion of the repeated boilerplate glue. Additionally, the data protocols are also fairly standardized in Plan 9; The typical format is tabular plain text with '%q'-verb quoting.
There's a reason that the 9front implementation of things usually ends up at about 10% the size of the upstream.