(originally posted on slashdot in this post)

This means that all applications must be decoupled from their interfaces, and that's nontrivial if possible at all.

It is likely to be impossible for existing applications to be thus decoupled retroactively, but I suspect that, with suitable specifications, new applications could reasonably be written decoupled from their interfaces.

The ideal interface would probably be a multiplexed text stream of some sort, where the user would send commands to the program and it would respond in one main virtual stream using additional data in other virtual streams. The data would conform to some content specification. In practice, nobody (except people debugging the program) would use the raw interface, but would instead use a front end which could be shared across applications which would render the various programs in a unified manner, and would be chosen (and configured) by the user.

The main problems I see are:

• Coming up with a sufficiently general specification. Possibly something related to HTML would be good (I've written a program that used HTTPS as the interface, and that worked well), with suitable standards for other content types. There's still the program of creating the spec and keeping people from stuffing incompatible extensions in on one side or the other.
• Handling applications which are mostly interfaces. For example, a wysiwyg word processor is actually a display for a markup language of some sort which can print it and has built-in commands to add particular bits of markup. It's unclear what (if anything) is not the user interface (i.e., would be the back end) in this case.
• Also, applications with very specific sorts of interface necessarily attached. For example, the game of Go. There's a board on which players place pieces. It requires a great deal of imagination to come up with a text-only or voice-only interface, and it clearly would be impossible to specify Go in such a way that a front end that was not specifically for Go would present a good interface. (especially since the front end might be voice-only)

On the other hand... there are a couple of protocols suitable for playing Go on the internet. There are quite a few entirely different clients which speak these protocols (even to a local back end) and which look remarkably different, and some of the protocols make it possible (although not easy) to play with plain text, just using telnet. So maybe the problems are not insurmountable after all.