5 ms·

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 pre

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.)
    - cryptonector 4y ago
      In hindsight everything should be HTTP, and there should be JSON schemas as an option for everything. Not needing the bloat of an LDAP implementation is very nice. Schema differences between sites and schema metastasis into code in ways that complicate schema evolution is a big deal too, so "stored procedures" are really a good idea for containing schema metastasis. I'm not sure why GP would need service discovery for DNS zone updates via SMTP though.
      - vidarh 4y ago
        Mail servers have a bunch of tooling for routing, retries, queue management etc. that already exists. If you do that via HTTP you end up having to reinvent a full message broker stack just for the sake of using a different protocol that lacks the abundance of components you can just drop in to do things like reflection (mailing lists), forwarding, filtering, retrieval, deletion, access control that you get for free with a mail server. Maybe if we that entire ecosystem existed on top of HTTP it'd have been ok, but the actual transport is the tiniest little uninteresting sliver of what we got by using a mail server for queuing. With respect to the DNS servers, the service discovery was for addressing, so we/a client component could e.g. e-mail "update@dns.live.local" or similar. The SMTP updated one was not the service discovery one, but feeding our customer facing DNS infrastructure.
        cryptonector 4y ago
        There's several ways of doing service discovery for HTTP services like this in an enterprise, using 3xx replies to redirect if you move the service. The simplest is to just use a URI authority that you can change as needed. The next simplest is to publish URI RRs in DNS. The next simplest is to use the .well-known URI local-part namespace to include information for client-side routing. Granted, the last two are recent developments.
        vidarh 4y ago
        Or we could just use DNS A or CNAME records and not have to do any of those, the way e.g. CoreDNS w/k8s or ldapdns on top of openldap, and similar does. There are use cases for more complicated service discovery, especially discovery of external services, but for the scenario I described, which in involved discovery within our own network this all just would have added extra complexity for no benefit that would have made any difference to us. Note that service discovery was not listed as one of the reasons I think http doesn't solve the issues that made us choose a mail server back then..the exact same service discovery mechanism would have worked just fine for http too. But we'd still have had to build all the message broker code from scratch instead of picking and choosing from pre-existing components.
denton-scratch 4y ago
MIME not only arrived after SMTP (the 'E' in MIME stands for 'extension'); it doesn't infect the SMTP part of the stack. There's nothing in SMTP that would have to change if MIME was abolished. SMTP provides no special support for MIME. They are disjoint. Since HTTP/1.1, HTTP hasn't been premised on HTML, and vice-versa; again they are disjoint. I don't know why author makes these claims.
drpixie 4y ago
HTTP might now be used for other things but right from the beginning (check the RFCs) HTTP stood for "Hypertext Transfer Protocol", the RFC was written by Berners-Lee. HTTP and HTML did come together, and from the same person.
- josephg 4y ago
  So? They aren’t bundled together as the article says they are. Even on the web HTTP is used for all sorts of other content types, from images to CSS, loading javascript, JSON RPC calls, websocket connections, server sent events and so on. Outside of the web? DoH, JSON RPC, git over https, npm, video games, elasticsearch queries, … the list goes on for a long time. A very small percent of http requests transmit html. Claiming http “bundles” html is like saying XmlHttpRequest is bundled with xml, or shortening javascript to Java. It’s a strong signal that you don’t know what you’re talking about.
  - 0x445442 4y ago
    The HTTP verbs don’t support RPC unless you violate their specified operations. Add DO to GET, PUT, POST, PATCH and DELETE along with expanded response codes and I’m good.
    - remram 4y ago
      Why not use POST?
    - cryptonector 4y ago
      You can add verbs.
    - toast0 4y ago
      All those verbs are just constants that provide some behavior. POST is the constant that means I'm going to probably send you a body and probably nobody is going to try to add caching, which is usually what you want from an RPC. You can just #define DO POST, and you're set.

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.)
  - cryptonector 4y ago
    In hindsight everything should be HTTP, and there should be JSON schemas as an option for everything. Not needing the bloat of an LDAP implementation is very nice. Schema differences between sites and schema metastasis into code in ways that complicate schema evolution is a big deal too, so "stored procedures" are really a good idea for containing schema metastasis. I'm not sure why GP would need service discovery for DNS zone updates via SMTP though.
    - vidarh 4y ago
      Mail servers have a bunch of tooling for routing, retries, queue management etc. that already exists. If you do that via HTTP you end up having to reinvent a full message broker stack just for the sake of using a different protocol that lacks the abundance of components you can just drop in to do things like reflection (mailing lists), forwarding, filtering, retrieval, deletion, access control that you get for free with a mail server. Maybe if we that entire ecosystem existed on top of HTTP it'd have been ok, but the actual transport is the tiniest little uninteresting sliver of what we got by using a mail server for queuing. With respect to the DNS servers, the service discovery was for addressing, so we/a client component could e.g. e-mail "update@dns.live.local" or similar. The SMTP updated one was not the service discovery one, but feeding our customer facing DNS infrastructure.
      - cryptonector 4y ago
        There's several ways of doing service discovery for HTTP services like this in an enterprise, using 3xx replies to redirect if you move the service. The simplest is to just use a URI authority that you can change as needed. The next simplest is to publish URI RRs in DNS. The next simplest is to use the .well-known URI local-part namespace to include information for client-side routing. Granted, the last two are recent developments.
        vidarh 4y ago
        Or we could just use DNS A or CNAME records and not have to do any of those, the way e.g. CoreDNS w/k8s or ldapdns on top of openldap, and similar does. There are use cases for more complicated service discovery, especially discovery of external services, but for the scenario I described, which in involved discovery within our own network this all just would have added extra complexity for no benefit that would have made any difference to us. Note that service discovery was not listed as one of the reasons I think http doesn't solve the issues that made us choose a mail server back then..the exact same service discovery mechanism would have worked just fine for http too. But we'd still have had to build all the message broker code from scratch instead of picking and choosing from pre-existing components.

denton-scratch 4y ago

MIME not only arrived after SMTP (the 'E' in MIME stands for 'extension'); it doesn't infect the SMTP part of the stack. There's nothing in SMTP that would have to change if MIME was abolished. SMTP provides no special support for MIME. They are disjoint. Since HTTP/1.1, HTTP hasn't been premised on HTML, and vice-versa; again they are disjoint. I don't know why author makes these claims.

drpixie 4y ago

HTTP might now be used for other things but right from the beginning (check the RFCs) HTTP stood for "Hypertext Transfer Protocol", the RFC was written by Berners-Lee. HTTP and HTML did come together, and from the same person.

josephg 4y ago
So? They aren’t bundled together as the article says they are. Even on the web HTTP is used for all sorts of other content types, from images to CSS, loading javascript, JSON RPC calls, websocket connections, server sent events and so on. Outside of the web? DoH, JSON RPC, git over https, npm, video games, elasticsearch queries, … the list goes on for a long time. A very small percent of http requests transmit html. Claiming http “bundles” html is like saying XmlHttpRequest is bundled with xml, or shortening javascript to Java. It’s a strong signal that you don’t know what you’re talking about.
- 0x445442 4y ago
  The HTTP verbs don’t support RPC unless you violate their specified operations. Add DO to GET, PUT, POST, PATCH and DELETE along with expanded response codes and I’m good.
  - remram 4y ago
    Why not use POST?
  - cryptonector 4y ago
    You can add verbs.
  - toast0 4y ago
    All those verbs are just constants that provide some behavior. POST is the constant that means I'm going to probably send you a body and probably nobody is going to try to add caching, which is usually what you want from an RPC. You can just #define DO POST, and you're set.