Chorus, a brief overview
Just to give a sense of the direction I'm going with the chorus terminal, here are some of the very high-level ideas that go into it:
- Programs should be able to exchange structured self-describing data and messages, not just flat streams of bytes. The current design supports this by adding a new set of streams, msgin and msgout, to the existing stdin, stderr, and stdout.
- It's time for the terminal to become graphical. Programs will get access to a graphical DOM in the terminal which provides a convenient way to display arbitrary graphics. The terminal DOM model is partly inspired by – but much simpler and cleaner than – the HTML DOM.
- The terminal and shell should assume more responsibility for interacting with the surrounding system. You shouldn't have to bake a library into your program to be able to do even simple things like command line editing, or reading URLs, etc. If you can place that functionality in the shell and access it through messages you get smaller, simpler, and more flexible programs.
- There is lots of potential for better security. If a program's interaction with the system goes through the shell then you can isolate the program and tightly control what it's allowed to do and how.
- Chorus will not be derived from any existing tools – but is will be backwards compatible with them. The new functionality comes in addition to what you're used to from a terminal.
- It will be cross-platform. I'm aiming for windows first to keep myself honest – I'm more at home on linux myself – and the other big platforms will follow.
A lot of interesting possibilities open up once you have infrastructure like this in place. This is really just the starting point.
If you have any thoughts or input on this consider letting me know on the mailing list, firstname.lastname@example.org. And if you haven't already you can sign up for project updates on the main page.