5 ms·

There's nothing inherently 'web' or 'slow' or 'ajaxy' about Gzipped-JSON-over-HTTP2. I agree that the web is slow and crap a lot of the time, but chat using gz

There's nothing inherently 'web' or 'slow' or 'ajaxy' about Gzipped-JSON-over-HTTP2. I agree that the web is slow and crap a lot of the time, but chat using gzipped JSON over HTTP/2 would be just as fast as IRC as long as it's only sending the same level of info as IRC.

zAy0LfpBZLC8mAC 10y ago
And yet it requires a hilariously complex protocol engine for HTTP for no purpose whatsoever.
- milesrout 10y ago
  I don't agree at all. HTTP/1.1 and HTTP/2 are not especially simple protocols, but they're not that complicated. They aren't unnecessarily complicated, that's for sure. They have a set of features that necessitates a level of complexity, but it's better to do it in HTTP/2 once and only once than to repeat the same failures and reworks and added features and upgrades etc. etc. etc. to get the same level of features in a million different application protocols. Because otherwise you'll get to the same place as we were with HTTP/1.1: your nice 'simple' protocol will need to be replaced with one that can support multiple streams, etc.
  - zAy0LfpBZLC8mAC 10y ago
    > They aren't unnecessarily complicated They are, for what matrix intends to do.
    - srssays 10y ago
      Programming sucked before HTTP+JSON became the lingua franca of machine communication. Being able to use any programming language with modern HTTP-based protocols is a real luxury. Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one. This was so crippling that XML actually seemed like a good idea. Just imagine!
      - zAy0LfpBZLC8mAC 10y ago
        > Being able to use any programming language with modern HTTP-based protocols is a real luxury. No, it's not, it's a huge pile of crap, because HTTP is so complicated that you essentially have to distrust any implementation of it that you haven't audited, and even then, it's questionable (plus, most implementations turn out to be buggy if you look closely, and serious vulnerabilities aren't exactly uncommon), and it doesn't even fit many common scenarios without additional hacks like long polling. Also, "any programming language" is a huge exaggeration. Ever used HTTP on a microcontroller? > Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one. Now, that's just bullshit. If you have an HTTP implementation, you necessarily also have a TCP implementation. You don't need to write anything in order to use TCP, you just open a socket and use it and forget about HTTP. HTTP serves no purpose in most cases. Oh, and maybe more importantly: Ever used HTTP for peer-to-peer communication? No, you need a server! Because it's so much more convenient to add a server "in the cloud" than to simply use a TCP connection between two devices that need to communicate. (And no, of course, you technically don't need a server, but in practice that's how people deal with the pointless complexity of HTTP.)
        photojosh 10y ago
        I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller. The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it with raw sockets I'd have to reimplement many of those layers and write a mobile app as opposed to a mobile webpage with only 300 lines of JS. > Ever used HTTP for peer-to-peer communication? Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to. One of the nodes connects to a public server and has other private nodes connect to it. (300 lines of Python/Twisted)
        10y ago

zAy0LfpBZLC8mAC 10y ago

And yet it requires a hilariously complex protocol engine for HTTP for no purpose whatsoever.

milesrout 10y ago
I don't agree at all. HTTP/1.1 and HTTP/2 are not especially simple protocols, but they're not that complicated. They aren't unnecessarily complicated, that's for sure. They have a set of features that necessitates a level of complexity, but it's better to do it in HTTP/2 once and only once than to repeat the same failures and reworks and added features and upgrades etc. etc. etc. to get the same level of features in a million different application protocols. Because otherwise you'll get to the same place as we were with HTTP/1.1: your nice 'simple' protocol will need to be replaced with one that can support multiple streams, etc.
- zAy0LfpBZLC8mAC 10y ago
  > They aren't unnecessarily complicated They are, for what matrix intends to do.
  - srssays 10y ago
    Programming sucked before HTTP+JSON became the lingua franca of machine communication. Being able to use any programming language with modern HTTP-based protocols is a real luxury. Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one. This was so crippling that XML actually seemed like a good idea. Just imagine!
    - zAy0LfpBZLC8mAC 10y ago
      > Being able to use any programming language with modern HTTP-based protocols is a real luxury. No, it's not, it's a huge pile of crap, because HTTP is so complicated that you essentially have to distrust any implementation of it that you haven't audited, and even then, it's questionable (plus, most implementations turn out to be buggy if you look closely, and serious vulnerabilities aren't exactly uncommon), and it doesn't even fit many common scenarios without additional hacks like long polling. Also, "any programming language" is a huge exaggeration. Ever used HTTP on a microcontroller? > Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one. Now, that's just bullshit. If you have an HTTP implementation, you necessarily also have a TCP implementation. You don't need to write anything in order to use TCP, you just open a socket and use it and forget about HTTP. HTTP serves no purpose in most cases. Oh, and maybe more importantly: Ever used HTTP for peer-to-peer communication? No, you need a server! Because it's so much more convenient to add a server "in the cloud" than to simply use a TCP connection between two devices that need to communicate. (And no, of course, you technically don't need a server, but in practice that's how people deal with the pointless complexity of HTTP.)
      - photojosh 10y ago
        I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller. The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it with raw sockets I'd have to reimplement many of those layers and write a mobile app as opposed to a mobile webpage with only 300 lines of JS. > Ever used HTTP for peer-to-peer communication? Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to. One of the nodes connects to a public server and has other private nodes connect to it. (300 lines of Python/Twisted)
        10y ago