> Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;)
Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions.
> Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes
Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone.
> This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
What exactly would people facepalming and walking off feel like, that this doesn't feel like it?
In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one.
(And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)