Post

jyn.devthe terminal of the futureTo redesign infrastructure, you have to allow incremental adoption, while simultaneously moving the whole design space at once.

Re: jyn.dev/the-terminal... I would love to chat about the stuff I'm doing with postcard-rpc/ergot but also poststation: I'm building a typed, autodiscoverable, lightweight socket library that I'm using as a network transport library but also I want to make it my hobby os' syscall/ipc interface

James Munns

@jamesmunns.com

But hell yeah: it is possible to do VERY efficient, typed, comms languages, and building in autodiscovery is like having mdns+openapi, which you can use to make very very neat cli + gui tools. I really want to make things like old smalltalk system browser for network services.

James Brundage | MVP

@mrpowershell.com

James to James, if you want this, please help build it. I've been working these angles for a while and everything needs help to get over the finish line and out into the community. 🙏 help build some cool #PowerShell #WebDev projects 😉

"structured messages with built-in reflection" is the dream, yeah. i want something like powershell Get-Member for every process in my shell, every feature of my terminal emulator, every part of the line editor!

James Munns

@jamesmunns.com

"content addressable endpoints" x "content addressable schemas" x "enumerable devices/servers/applications" is such a nice place to be. I would love to build a little dynamically loaded shell/repl to talk to a small network of devices/servers/applications once I get a little further w/ergot.

James Brundage | MVP

@mrpowershell.com

Me too! As someone who has been doing #Terminal dev and #WebDev with #PowerShell for a long time, I think we should talk. A bunch of stuff coming down my pike hits a bunch of points in your essay.

James Brundage | MVP

@mrpowershell.com

💯 interesting thoughts. Been working at this for a while. 1000 foot "here's how" 1. PowerShell has an object pipeline, events, and thread jobs; use them. 2. Everything fast goes thru HTTP / WebSockets on randomized loopback ports. 3. Everything else goes thru .NET api or CLI parsing. 80% there

the goal is not to build a xterm-killer, the goal is to teach people to yearn for the vast and boundless sea

I think anyone looking to implement a "better terminal experience" should really take a look at plan9port's drawterm/rc mainly how line editing is moved into being the responsibility of the WM/terminal, instead of the shell, which has way better network performance.

no mention of ioctl? ioctls suck for a billion reasons, from inflexibility and bad support to fundamental issues with in-band signaling.

which kind of ioctls? i was kinda hoping for the server to smooth over nasty impl details like this so the client doesn’t have to worry about them, but maybe i am underestimating how much they impact the interface?

ioctls as i've interacted with them mainly exist in the interface between cli tool and PTY. I don't have a ton of experience with them, I mainly just remember how miserable they felt to use directly.

also, if i was reimagining terminals, i would add non-text widgets with a simple line-based layout algorithm, sort of like tcl wish... hmm now i wonder if you could make a program that turns ANSI escapes into TCL widgets...

i’m not sure i follow, tcl wish seems to be a REPL? how are layouts related? yes, something i would want from the “structured rpc” step is a way for the process to request creating an interactive widget. but that requires changes to the process, and there are a million CLI programs in the world.