> Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way.
This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it.
For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.
> But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
I think the fundamental change is that, given a classic Internet protocol, I can look at it and learn how it works without having to already have a tool to understand it. I can look at a stream of POP, SMTP, HTTP, FTP, IRC, NNTP, IMAP... the list really does go on and on... and even if I've never seen the protocol before, even if I don't know what the protocol is called, I can sort of figure out how to speak it.
The downside, of course, being that people then think they can speak these protocols, and build horrible "almost sort of" clients for them that fail to interoperate correctly :/. BUT, there is still this interesting egalitarian concept that these protocols are designed for people in some very real way. I love network protocols. I've implemented a ton of them over the years. I got into them at a very young age. Part of the reason why I got into them is because they were just so darned accessible. It makes me a little sad to see this aspect go away.
This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it.
For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.