| Here's my shot: - curl sees that the standard output is a tty, consults $TERM, termcap, etc - curl crafts an "Accept:" header, format to be specified - server sees Accept and responds with appropriately encoded response; e.g. for text/plain it would just output preformatted text As this is currently NOT a common use case (mostly fun toys, biggest use case is Github printing out a pride flag), the exact content type can be easily iterated on to standardise it. For example, the most common cases (TERM=xterm or xterm-256color) could be specified in the standard and treated as abbreviations for the complete description of capabilities. The server can have those common cases built-in, but it should also be free to ignore any capabilities it doesn't understand and send out a conservative response. All of these smarts could be a part of a library or framework. I made this up on the spot, it's not hard, because the entire stack is adequately layered. So just don't break those layers, m'kay? |