4 ms·

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial e

by twiss 4y ago

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial effect. The Area Tech Leads of Cloud also failed to convince their peers in Chrome, and as a result, trailers were ripped out [from the WHATWG fetch specification]. FWIW, I personally think it's a good thing that other teams within Google don't have too much of an "advantage" for getting features into Chrome, compared to other web developers, however, I also think it's very unfortunate that a single Chrome engineer gets to decide not only that it shouldn't be implemented in Chromium, but that that also has the effect of it being removed from the specification. (The linked issue [1] was also opened by a Google employee.) Of course, you might reasonably argue that, without consensus among the browsers to implement a feature, having it in the spec is useless. But nevertheless, with Chromium being an open source project, I think it would be better if it had a more democratic process of deciding which features should be supported (without, of course, requiring Google specifically to implement them, but also without, ideally, giving Google the power to veto them). [1]: https://github.com/whatwg/fetch/issues/772 https://github.com/whatwg/fetch/issues/772

modeless 4y ago
It's clear that the "single engineer" thing is a lie. Many engineers commented on the Chrome issue with opposing viewpoints, and even the original post describes it being escalated to tech leads on both sides, getting more people involved. I guarantee if it was only one person standing alone opposed to trailers then they would have been overruled. As you say, it's a good thing that Chrome resists adding the pet features of every other Google team to the web.
- guenthert 4y ago
  Jeebus. Just because it's not true doesn't mean it's a lie.
  - modeless 4y ago
    It's a lie if OP knows it isn't true. And OP knows it isn't true because they explicitly describe a lot more than one person being involved on both sides.
- twiss 4y ago
  Sure, that's fair enough. But I'm not sure if characterizing this feature as a pet feature of the gRPC team is accurate either - after all, it's simply exposing an HTTP 1.1 & H2 feature, and it was already in the WHATWG fetch spec. There, the security concerns were apparently discussed as well [1], and adding the trailer headers as a separate object was deemed safe. I haven't read the entire discussion and don't have a vested interest in it, but the WHATWG spec seems like a better place to have this discussion, and come to a conclusion, than the Chromium issue tracker. Apparently, there is a new issue for it, so that might yet happen: [2]. [1]: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34 [2]: https://github.com/whatwg/fetch/issues/981 https://github.com/whatwg/fetch/issues/981
  - raggi 4y ago
    This could be solved without trailers by piggybacking on top of server sent events rather than requests with trailers, and terminating a stream with status metadata as a final event.
    - Matthias247 4y ago
      Server sent events are just a potential payload format for response bodies, which allows to encode a potentially infinite amount of distinct messages. Trailers are a different concept since they exist outside of bodies. If the team had decided to only use http body streams for all payload, they could totally have done that without directly using SSE encoding.
      - raggi 4y ago
        SSE adds another thing besides the body encoding, which is a standard content type that implies unbuffered streaming.
    - paulgb 4y ago
      The underlying data is binary (protobufs), though. It would defeat the purpose to re-encode it as text to send over SSE. Also, IIRC gRPC supports full-duplex, which SSE does not. WebSockets may have been a better fit, as the Chromium developers hinted on the WontFix issue linked in the post.
fijiaarone 4y ago
I wanted my road to swoop up and down like a roller coaster across the gorge but a single structural engineer on the bridge team overruled my obvious benefit.
sneak 4y ago
Why should the decisionmaking process for Chromium be “democratic” simply because it is open source? Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time]. If Google is paying for the implementors’ time, Google should have 100% say in what code they write. You and everyone else are free (thanks to Google’s generosity) to fork it at any point in the commit history and individually veto any specific change.
- Brian_K_White 4y ago
  The democratic process is that anyone who wants to pay for the ad campaign can try to convince everyone else that it's a good spec everyone should adopt, not merely pay a developer to code it. If everyone else is not convinced then it should not become a thing no matter how much one party with money wants it.
- twiss 4y ago
  > Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time]. Leaving aside whether that's how it should work, I'm not sure if that's in fact how it works for Chromium today. If I write a high-quality patch adding support for trailers, will it get accepted? As I understand it, the answer is no. (But I would be happy to be wrong.) So that's my main point: it would be good to have a democratic decision making process, not for what code Googlers should write, but for what patches would get accepted into Chromium. Not just because it's open source, but also because it's the basis not just of Google's browser, but a bunch of other browsers as well. (And note that https://www.chromium.org/ https://www.chromium.org/ seemingly aims to give the project an air of independence from Google. Thus, I'm merely questioning whether it is, in fact, independent, and arguing that it should be, if it isn't.)

by twiss 4y ago

modeless 4y ago

It's clear that the "single engineer" thing is a lie. Many engineers commented on the Chrome issue with opposing viewpoints, and even the original post describes it being escalated to tech leads on both sides, getting more people involved. I guarantee if it was only one person standing alone opposed to trailers then they would have been overruled. As you say, it's a good thing that Chrome resists adding the pet features of every other Google team to the web.

guenthert 4y ago
Jeebus. Just because it's not true doesn't mean it's a lie.
- modeless 4y ago
  It's a lie if OP knows it isn't true. And OP knows it isn't true because they explicitly describe a lot more than one person being involved on both sides.
twiss 4y ago
Sure, that's fair enough. But I'm not sure if characterizing this feature as a pet feature of the gRPC team is accurate either - after all, it's simply exposing an HTTP 1.1 & H2 feature, and it was already in the WHATWG fetch spec. There, the security concerns were apparently discussed as well [1], and adding the trailer headers as a separate object was deemed safe. I haven't read the entire discussion and don't have a vested interest in it, but the WHATWG spec seems like a better place to have this discussion, and come to a conclusion, than the Chromium issue tracker. Apparently, there is a new issue for it, so that might yet happen: [2]. [1]: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34 [2]: https://github.com/whatwg/fetch/issues/981 https://github.com/whatwg/fetch/issues/981
- raggi 4y ago
  This could be solved without trailers by piggybacking on top of server sent events rather than requests with trailers, and terminating a stream with status metadata as a final event.
  - Matthias247 4y ago
    Server sent events are just a potential payload format for response bodies, which allows to encode a potentially infinite amount of distinct messages. Trailers are a different concept since they exist outside of bodies. If the team had decided to only use http body streams for all payload, they could totally have done that without directly using SSE encoding.
    - raggi 4y ago
      SSE adds another thing besides the body encoding, which is a standard content type that implies unbuffered streaming.
  - paulgb 4y ago
    The underlying data is binary (protobufs), though. It would defeat the purpose to re-encode it as text to send over SSE. Also, IIRC gRPC supports full-duplex, which SSE does not. WebSockets may have been a better fit, as the Chromium developers hinted on the WontFix issue linked in the post.

fijiaarone 4y ago

I wanted my road to swoop up and down like a roller coaster across the gorge but a single structural engineer on the bridge team overruled my obvious benefit.

sneak 4y ago

Why should the decisionmaking process for Chromium be “democratic” simply because it is open source? Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time]. If Google is paying for the implementors’ time, Google should have 100% say in what code they write. You and everyone else are free (thanks to Google’s generosity) to fork it at any point in the commit history and individually veto any specific change.

Brian_K_White 4y ago
The democratic process is that anyone who wants to pay for the ad campaign can try to convince everyone else that it's a good spec everyone should adopt, not merely pay a developer to code it. If everyone else is not convinced then it should not become a thing no matter how much one party with money wants it.
twiss 4y ago
> Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time]. Leaving aside whether that's how it should work, I'm not sure if that's in fact how it works for Chromium today. If I write a high-quality patch adding support for trailers, will it get accepted? As I understand it, the answer is no. (But I would be happy to be wrong.) So that's my main point: it would be good to have a democratic decision making process, not for what code Googlers should write, but for what patches would get accepted into Chromium. Not just because it's open source, but also because it's the basis not just of Google's browser, but a bunch of other browsers as well. (And note that https://www.chromium.org/ https://www.chromium.org/ seemingly aims to give the project an air of independence from Google. Thus, I'm merely questioning whether it is, in fact, independent, and arguing that it should be, if it isn't.)