Hacker News Reader

Comment by cturner | Hacker News Reader

You can and should separate view and controller. Imagine if you could spawn windows at monitors, and then have things display on them via pipeline.

You might type into a tiny window on one monitor that never loses focus, but sends graphs and text and streams to these windows.

There's no reason that the place you enter text should correspond to the output display, and a lot of value to be had by separating them.

Imagine being able to plug display consumers into a port so that you could do visual demos.

View on HN

Most unixy programs actually do have them divided. stdin, stdout (and a third for stderr). It would be very easy to separate the streams to different places.

ETA at the last place I worked, we actually had the touchscreen on one desk and the program running in a window on another computer. It was pretty nice to type something and make it show up across the room.

On this topic of stdin, stdout - wouldn't it be neat if - instead of signals - there was an input channel called stdctrl that you could send control messages in on.

Glad to read about the scenario at your last place - I've never seen this in action.

Well, it's not exactly what you describe (which does sound kind of intriguing), but Linux does offer the signalfd(2) syscall, which allows you to read signals from a file descriptor. Doesn't do much for the sender of said signals, however.

At AOL circa 2000, our application framework had a Tcl interpreter listening on a "control port", so that you could telnet to any app and get stats, change settings, etc.

Of course, nowadays that's more commonly done with REST endpoints, which I think would satisfy your stdctrl idea.

Well those are just the defaults, a program can open a lot more sockets if it wants to. IPC is an old problem with a lot of pretty good solutions by now.

I think Plan 9 does something similar. You send signals to a process by writing to a file in the process's /proc directory.

The concept of a view and a controller are distinct, a terminal simply happens to be both, because it can do both. Commands are solely controllers, and you're right, a read-only terminal would be just a view.

Reply on news.ycombinator.com