3 ms·

I agree, this RFC seems to propose a great deal of different additions/changes to the HTTP protocol without a unifying reason why. But the committee/process is

I agree, this RFC seems to propose a great deal of different additions/changes to the HTTP protocol without a unifying reason why. But the committee/process is all in the open, through the IETF, so now is the time to voice your concerns! > Reading the RFC, this seems to make HTTP stateful The reasoning behind this seems to be that the alternatives right now are either polling or a homegrown websocket based protocol. The authors argue that rather than continuing to let different implementors make bespoke or otherwise non-standard polling/subscription based websocket implementations, to standardize on a RESTful way to subscribe to a stream of updates. > It also uses PUT to patch things, but then why not use PATCH ? You could say it's non standard, but at this point, everybody uses it. Plus their stuff is apparently deviate from the original standard as well by allowing headers after the first line of the payload and introducing the forGET command. I've personally seen both PUT and PATCH used for updates, so this didn't seem particularly odd to me, and seemed more like a nod to one particular method of updates. But yes, the overall RFC is proposing to modify HTTP from a state transfer protocol to a state synchronization protocol, so that clients and servers have to hold onto state and send diffs between their internal states, and then implement some reconciliation algorithm (e.g. OTs or CRDTs) to merge state. This seems like it is in response to a myriad of bespoke long-polling or websocket based update mechanisms. > They also mention a really cool RFC on a JSON patch format: https://datatracker.ietf.org/doc/html/rfc6902 https://datatracker.ietf.org/doc/html/rfc6902 Yup! Super cool right? > I'm reading RFC and getting excited about it. Damn, that must be what they call growing old. Well, you could do that, or you could read yet another article about startup financials, which is all that seems to trend on HN these days ;)

toomim 7y ago
> this RFC seems to propose a great deal of different additions/changes to the HTTP protocol without a unifying reason why To read more of the unifying why, I suggest checking out the original Braid draft from last July: https://datatracker.ietf.org/doc/html/draft-toomim-braid-00 https://datatracker.ietf.org/doc/html/draft-toomim-braid-00. We had a much longer introduction in that version, but shortened it in braid-http-01 so that we could cut to the meat. If the why still isn't clear after reading braid-00, please let us know on the mailing list: https://groups.google.com/forum/#!forum/braid-http https://groups.google.com/forum/#!forum/braid-http. And on the other hand, if something in braid-00 helped, we'd also love to hear what, so that we can add that back into the braid-http-01 draft.
- Karrot_Kream 7y ago
  I really found these lines in braid-00 > Braid is a proposal for a new version of HTTP that transforms it from a state transfer protocol into a state synchronization protocol. Braid puts the power of Operational Transform and CRDTs onto the web, improving network performance and robustness, and enabling peer-to-peer web applications. > At the same time, Braid creates an open standard for the dynamic internal state of websites. Programmers can access state uniformly, whether local or on another website. This creates a separation of UI from State, and allows any user to edit or choose their own UI for any website's state. to be very useful to set the overall motivation. If I could humbly request, I think having them in subsequent drafts would be very nice! Thanks for the reply and thanks for all the good work!
  - toomim 7y ago
    Will do! Thank you very much!
- BiteCode_dev 7y ago
  I really like the RFC. Two questions: - do you think it would make sense to allow the "Patches" header only in PATCH and not PUT? - how do you feel about a generic "subscribe" mechanism that is not specific to sync but can just say "I'm interested in this topic, with this params" ? Then this could be specialized with the version+parents params to get sync. This way we get a generic HTTP standard for PUB/SUB, which is badly needed, and is a very basic primitive you can build many things on. It would be a shame to have to add one after the fact.
  - Karrot_Kream 7y ago
    > "I'm interested in this topic, with this params" Couldn't you just do this with URIs? Like if you "GET /topic/foo" with a Subscribe header you get the foo topic, and "GET /topic/bar" gets the bar topic?
    - BiteCode_dev 7y ago
BiteCode_dev 7y ago
> The reasoning behind this seems to be that the alternatives right now are either polling or a homegrown websocket based protocol. Right. Same with routed RPC and routed PUB/SUB. I currently use the WAMP (protocol, not stack) for that, as it is a Webocket based IANA standard, but with http2/3, having the HTTP version of it would make sense to have this baked in as well. In fact, their subscribe thingy should probably be more generic and accept a topic and optional params. Params could be then use to upgrade the use case, like version+parents for sync. Plus client may want to push events as well. I don't know how one can contribute to the debate. Would you explain it to me? > I've personally seen both PUT and PATCH used for updates, so this didn't seem particularly odd to me, and seemed more like a nod to one particular method of updates. PUT in REST is for sending the full object, PATCH is for partial updates. So both are valid, but I would allow the "Patches" headers for the PATCH method only.
- toomim 7y ago
  > I don't know how one can contribute to the debate. Would you explain it to me? The official venue for IETF discussions is the mailing lists. Braid is being discussed in the HTTP Working Group, on this mailing list: ietf-http-wg@w3.org. I suggest drafting an email saying something like: "Hi, I learned about the Braid spec on Hacker News. I am interested in it for reasons X, Y, and Z. Overall, my thoughts on the spec are W. However, the current draft allows sending patches in PUT, POST, and PATCH, and I would only allow the Patches header in the PATCH method. Does anyone have thoughts on this?" Thank you! I'd love to have your thoughts contribute to the consensus process.

toomim 7y ago

> this RFC seems to propose a great deal of different additions/changes to the HTTP protocol without a unifying reason why To read more of the unifying why, I suggest checking out the original Braid draft from last July: https://datatracker.ietf.org/doc/html/draft-toomim-braid-00 https://datatracker.ietf.org/doc/html/draft-toomim-braid-00. We had a much longer introduction in that version, but shortened it in braid-http-01 so that we could cut to the meat. If the why still isn't clear after reading braid-00, please let us know on the mailing list: https://groups.google.com/forum/#!forum/braid-http https://groups.google.com/forum/#!forum/braid-http. And on the other hand, if something in braid-00 helped, we'd also love to hear what, so that we can add that back into the braid-http-01 draft.

Karrot_Kream 7y ago
I really found these lines in braid-00 > Braid is a proposal for a new version of HTTP that transforms it from a state transfer protocol into a state synchronization protocol. Braid puts the power of Operational Transform and CRDTs onto the web, improving network performance and robustness, and enabling peer-to-peer web applications. > At the same time, Braid creates an open standard for the dynamic internal state of websites. Programmers can access state uniformly, whether local or on another website. This creates a separation of UI from State, and allows any user to edit or choose their own UI for any website's state. to be very useful to set the overall motivation. If I could humbly request, I think having them in subsequent drafts would be very nice! Thanks for the reply and thanks for all the good work!
- toomim 7y ago
  Will do! Thank you very much!
BiteCode_dev 7y ago
I really like the RFC. Two questions: - do you think it would make sense to allow the "Patches" header only in PATCH and not PUT? - how do you feel about a generic "subscribe" mechanism that is not specific to sync but can just say "I'm interested in this topic, with this params" ? Then this could be specialized with the version+parents params to get sync. This way we get a generic HTTP standard for PUB/SUB, which is badly needed, and is a very basic primitive you can build many things on. It would be a shame to have to add one after the fact.
- Karrot_Kream 7y ago
  > "I'm interested in this topic, with this params" Couldn't you just do this with URIs? Like if you "GET /topic/foo" with a Subscribe header you get the foo topic, and "GET /topic/bar" gets the bar topic?
  - BiteCode_dev 7y ago

BiteCode_dev 7y ago

> The reasoning behind this seems to be that the alternatives right now are either polling or a homegrown websocket based protocol. Right. Same with routed RPC and routed PUB/SUB. I currently use the WAMP (protocol, not stack) for that, as it is a Webocket based IANA standard, but with http2/3, having the HTTP version of it would make sense to have this baked in as well. In fact, their subscribe thingy should probably be more generic and accept a topic and optional params. Params could be then use to upgrade the use case, like version+parents for sync. Plus client may want to push events as well. I don't know how one can contribute to the debate. Would you explain it to me? > I've personally seen both PUT and PATCH used for updates, so this didn't seem particularly odd to me, and seemed more like a nod to one particular method of updates. PUT in REST is for sending the full object, PATCH is for partial updates. So both are valid, but I would allow the "Patches" headers for the PATCH method only.

toomim 7y ago
> I don't know how one can contribute to the debate. Would you explain it to me? The official venue for IETF discussions is the mailing lists. Braid is being discussed in the HTTP Working Group, on this mailing list: ietf-http-wg@w3.org. I suggest drafting an email saying something like: "Hi, I learned about the Braid spec on Hacker News. I am interested in it for reasons X, Y, and Z. Overall, my thoughts on the spec are W. However, the current draft allows sending patches in PUT, POST, and PATCH, and I would only allow the Patches header in the PATCH method. Does anyone have thoughts on this?" Thank you! I'd love to have your thoughts contribute to the consensus process.