4 ms·

Hmm, is readability the most important thing here? It seems like terseness may be indicated if this is for PATCH requests. Request bodies are almost never compr

Hmm, is readability the most important thing here? It seems like terseness may be indicated if this is for PATCH requests. Request bodies are almost never compressed. If the patch is too big, you'd be better off just sending the whole file rather than preparing a patch. The unix diff tool's output is very terse and it's a reliable workhorse.

shadowgovt 4y ago
In the 21st century, I rarely hear people suggest we substitute something for the UNIX format. Diff is great as a middle tool but is not nearly as self-descriptive as modern protocols try to be.
- electroly 4y ago
  When git had the chance to create its own diff format in 2005, it copied the unix diff format. I don't think it's a given that just because it's old, all of its design decisions are wrong. The lack of compression for PATCH request bodies and the need to be smaller than the original file seems, to me, to indicate terseness.
  - shadowgovt 4y ago
    I wasn't implying diff's design decisions were wrong, just that when we greenfield things these days, self-description is a feature where it decidedly wasn't in software built during the era where characters cost money (in ink and paper) to represent. Git was wise to copy diff for backwards compatibility with existing CLI tools because it is primarily accessed via command line. No such backwards-compatibility gain exists with a PATCH protocol over HTTP. In terms of terseness: when servers care about terseness these days, they use a non-ASCII-on-the-wire transport like GRPC. I believe that is out of scope for this RFC.
    - electroly 4y ago
      I think (without any kind of supporting evidence) that git chose to use terse diffs so they could be emailed to mailing lists. Git's diffs aren't backwards compatible with patch by default; I'm not sure that was the reason. All of that is to say: I think there are reasons why a modern patch format might reasonably choose terseness. (Personally, I would just push for request body compression. It's not common but it's not impossible, and then you get the best of both worlds. I bet the terse format compresses to roughly the same size as the verbose format.)

shadowgovt 4y ago

In the 21st century, I rarely hear people suggest we substitute something for the UNIX format. Diff is great as a middle tool but is not nearly as self-descriptive as modern protocols try to be.

electroly 4y ago
When git had the chance to create its own diff format in 2005, it copied the unix diff format. I don't think it's a given that just because it's old, all of its design decisions are wrong. The lack of compression for PATCH request bodies and the need to be smaller than the original file seems, to me, to indicate terseness.
- shadowgovt 4y ago
  I wasn't implying diff's design decisions were wrong, just that when we greenfield things these days, self-description is a feature where it decidedly wasn't in software built during the era where characters cost money (in ink and paper) to represent. Git was wise to copy diff for backwards compatibility with existing CLI tools because it is primarily accessed via command line. No such backwards-compatibility gain exists with a PATCH protocol over HTTP. In terms of terseness: when servers care about terseness these days, they use a non-ASCII-on-the-wire transport like GRPC. I believe that is out of scope for this RFC.
  - electroly 4y ago
    I think (without any kind of supporting evidence) that git chose to use terse diffs so they could be emailed to mailing lists. Git's diffs aren't backwards compatible with patch by default; I'm not sure that was the reason. All of that is to say: I think there are reasons why a modern patch format might reasonably choose terseness. (Personally, I would just push for request body compression. It's not common but it's not impossible, and then you get the best of both worlds. I bet the terse format compresses to roughly the same size as the verbose format.)