6 ms·

This paragraph is just wrong: "Another explanation is that the Internet has unnecessarily coupled the transport protocol with the rest of the RPC framework. Co

by manv1 4y ago

This paragraph is just wrong: "Another explanation is that the Internet has unnecessarily coupled the transport protocol with the rest of the RPC framework. Conflating the two naturally follows from the purpose-built examples I just gave: SMTP is bundled with MIME; SNMP is bundled with MIB; and HTTP is bundled with HTML. " I think at this point he's suffering from what old-timers used to call recto-cranial inversion.

codeflo 4y ago
I think I feel dumber for reading this. (The referenced paper by Ousterhout is quite good though, and doesn’t confuse the terminology. Maybe that one’s what HN should link and discuss.)
- matjet 4y ago
  To someone only weakly aware in this area, can you explain what is wrong with the statement? From a cursory view, these protocols indeed seem to normally carry the mentioned payloads.
  - lozenge 4y ago
    It's not like HTTP stops working if you choose to send something besides HTML. Most of its features still work and make sense for JSON payloads and the usual building blocks still work (eg HTTPS, load balancers, proxies, status codes, redirects...) There are a few bits that don't make sense eg cookies where the server sends something and the client is expected to remember it but they can just be ignored.
    - codeflo 4y ago
      Exactly. The HTTP standard doesn't really mention HTML, except tangentially in examples. And regarding cookies, there are even people who use cookies in RPC contexts, but this is rather rare, and as you said, entirely optional. Also, as a minor point, even when browsing the web, a minority of the actual requests deliver HTML -- most of them are for various kinds of media referenced by the HTML document.
cryptonector 4y ago
Agreed. MIME came after SMTP, for example, and HTTP is used for all sorts of not-HTML-or-hyper-anything stuff. That statement smacks me of "wow, HTTP is a pretty good RPC, but too bad it's only/mainly for transporting HTML, shucks!". The name of the protocol is not very representative anymore either of how it's used or how anyone should use it. If HTTP fits the bill, then use it and move on.
- derefr 4y ago
  And I keep saying that SMTP is a perfectly good message-queue broker message submission protocol (and POP a perfectly good message-queue broker:consumer protocol), but nobody ever listens. :P
  - tleilaxu 4y ago
    I listened, derefr. I listened. ;)
  - vidarh 4y ago
    I've not just used SMTP the protocol as a submission protocol, but used actual mail servers as the broker, in a production system. Back in '99 I co-founded a mail provider, and we got so used to abusing qmail (+ rewritten replacement components - any qmail installation becomes a Ship of Theseus thanks to the clear API between small components) that when we needed a message broker we used our internal DNS server for service discovery and our mail infra as the broker (and we had a DNS server where the zones could be updated via SMTP). It worked well, and let us reuse a lot of tooling.
    - derefr 4y ago
      > and we had a DNS server where the zones could be updated via SMTP Interesting — what was the message format (MIME type) you chose to use to describe the zone changes? Actually, were they even patch-files at all, or did you just fetch the zone data file from your DNS server, update it client-side, and then send an updated complete copy back in the body of the email message, to get de-enveloped directly into /var/named? With the benefit of hindsight, I'm guessing you'd agree that it would have been simpler to use an LDAP directory for service discovery; then you'd at least have a specced-out message format for updates (LDIF) to be sending to the queue. But then, OpenLDAP as a project only got started in 1998, so maybe you weren't even aware of its existence back then, and were stuck on YP/NIS for Intranet directory management (which has no similar useful extensibility.)

by manv1 4y ago

codeflo 4y ago

I think I feel dumber for reading this. (The referenced paper by Ousterhout is quite good though, and doesn’t confuse the terminology. Maybe that one’s what HN should link and discuss.)

matjet 4y ago
To someone only weakly aware in this area, can you explain what is wrong with the statement? From a cursory view, these protocols indeed seem to normally carry the mentioned payloads.
- lozenge 4y ago
  It's not like HTTP stops working if you choose to send something besides HTML. Most of its features still work and make sense for JSON payloads and the usual building blocks still work (eg HTTPS, load balancers, proxies, status codes, redirects...) There are a few bits that don't make sense eg cookies where the server sends something and the client is expected to remember it but they can just be ignored.
  - codeflo 4y ago
    Exactly. The HTTP standard doesn't really mention HTML, except tangentially in examples. And regarding cookies, there are even people who use cookies in RPC contexts, but this is rather rare, and as you said, entirely optional. Also, as a minor point, even when browsing the web, a minority of the actual requests deliver HTML -- most of them are for various kinds of media referenced by the HTML document.

cryptonector 4y ago

Agreed. MIME came after SMTP, for example, and HTTP is used for all sorts of not-HTML-or-hyper-anything stuff. That statement smacks me of "wow, HTTP is a pretty good RPC, but too bad it's only/mainly for transporting HTML, shucks!". The name of the protocol is not very representative anymore either of how it's used or how anyone should use it. If HTTP fits the bill, then use it and move on.

derefr 4y ago
And I keep saying that SMTP is a perfectly good message-queue broker message submission protocol (and POP a perfectly good message-queue broker:consumer protocol), but nobody ever listens. :P
- tleilaxu 4y ago
  I listened, derefr. I listened. ;)
- vidarh 4y ago
  I've not just used SMTP the protocol as a submission protocol, but used actual mail servers as the broker, in a production system. Back in '99 I co-founded a mail provider, and we got so used to abusing qmail (+ rewritten replacement components - any qmail installation becomes a Ship of Theseus thanks to the clear API between small components) that when we needed a message broker we used our internal DNS server for service discovery and our mail infra as the broker (and we had a DNS server where the zones could be updated via SMTP). It worked well, and let us reuse a lot of tooling.
  - derefr 4y ago
    > and we had a DNS server where the zones could be updated via SMTP Interesting — what was the message format (MIME type) you chose to use to describe the zone changes? Actually, were they even patch-files at all, or did you just fetch the zone data file from your DNS server, update it client-side, and then send an updated complete copy back in the body of the email message, to get de-enveloped directly into /var/named? With the benefit of hindsight, I'm guessing you'd agree that it would have been simpler to use an LDAP directory for service discovery; then you'd at least have a specced-out message format for updates (LDIF) to be sending to the queue. But then, OpenLDAP as a project only got started in 1998, so maybe you weren't even aware of its existence back then, and were stuck on YP/NIS for Intranet directory management (which has no similar useful extensibility.)