3 ms·

I think that text output protocol is the wrong way of thinking about it. It should be a rich data stream capable of advanced features like objective stuff. Thin

I think that text output protocol is the wrong way of thinking about it. It should be a rich data stream capable of advanced features like objective stuff. Think ps, but then you’re able to navigate the output and perform additional functions. I think a subset of html would work for this. I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.

benlivengood 4y ago
Unix chose the midpoint between raw unformatted byte input and output (*argv being a raw byte array and stdout being binary or not existing at all and outputs would be configured by whatever was passed into argv) and structured results or a typed-function interface (like COM or CORBA or XML). Either extreme would have been untenable for a cohesive simple operating system, but I do wish Unix had leaned a bit farther toward the typed-interface design. We even had all the ASCII file/group/record/unit control characters.
wruza 4y ago
Think ps, but then you’re able to navigate the output and perform additional functions We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).