@david_chisnall @swetland oh, that is the proper version of some stuff I've been thinking of for a while.
Namely, a terminal that would also support programs that produced HTML output *or* that serve a web application. (So for example, an HTML top variant that serves a real-time web UI.)
(Likely then you could also extend that terminal to have browser functionalities, so "open https://example.com" would turn a tab into a browser.)
The kernel bit didn’t care what the types were. I initially used MIME types, but it would also be fine to say ‘this pipe is actually an HTTP interface now’ and provide a web interface.
I’d love to have that with the SSH tunneling so I could connect to a remote machine and then have web interfaces for administrative tools on a local web browser, without any faffing with port forwarding.
@david_chisnall @coder @swetland that made me recall this https://lobste.rs/s/mtatsi/unix_shell_programming_next_50_years#c_p4ojir
After closing the whole https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-emulation/ saga and getting more hands on experience living mostly terminal-free since then, a recurring gripe is the dynamic side to "typed pipes".
UX for type-negotiation in clipboard and drag and drop is not good in general. Some of that is the WM designer's fault ('remember to press shift when pasting to exchange text/plain instead of application/rtf' or whatever'. Turning 'a | b | c' in the shell ecosystem into runtime type negotiation repeats the issue.
CLI evaluator can't know or specify which of the intersecting sets of types is desired and not inform the user about the possibilities or zero-match. You get cornered into probing dynamically or side-band databases again.
What I am curious about, and won't get around to being mostly burnt out on the whole shebang, is how another ELF section describing imports/exports and loader provided typeof(stdin) | typeof(stdout) would fare towards a 'a (html) | b (json) | c'' with feedback without execution.
