4 ms·

Reading the RFC, this seems to make HTTP stateful: "A subscription is different from a GET connection (e.g. a TCP connection, or HTTP/2 stream). If a client r

Reading the RFC, this seems to make HTTP stateful: "A subscription is different from a GET connection (e.g. a TCP connection, or HTTP/2 stream). If a client requests "Subscribe: keep-alive", then the subscription will be remembered even after the GET connection closes." 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 apparently deviates from the HTTP standard as well by allowing headers after the first line of the payload and introducing the forGET command. Or am I missing something ? Interesting anyway, especially the way they create of graph of unique ID to solve the ordering problem. Feels like Git. The flow of patch reminds me of react-redux. Plus it's great to have more geeky technical things on HN. I'm missing it, among all the news and start up things. 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 I'm reading RFC and getting excited about it. Damn, that must be what they call growing old.

Karrot_Kream 7y ago
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.
paulddraper 7y ago
> You could say it's non standard Isn't PATCH standard? What is non-standard about it?
- sansnomme 7y ago
  People don't use it and a lot of web frameworks don't have first class support for it. The main benefit is making the request more semantic. Idempotency etc. isn't always that useful on the protocol level so GET & POST is more than sufficient for most purposes.
- BiteCode_dev 7y ago
  PATCH became a standard in 2010 (https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789), I just never patched my brain with this new revision and had stale data.
  - paulddraper 7y ago
    9 year max-age; impressive.
toomim 7y ago
> this seems to make HTTP stateful Yes -- depending on how you look at it. HTTP already has cookies to implement stateful sessions. Braid does add subscriptions; but HTTP 1.1 and 2 also has keep-alive at the TCP level: https://en.wikipedia.org/wiki/HTTP_persistent_connection https://en.wikipedia.org/wiki/HTTP_persistent_connection > It also uses PUT to patch things, but then why not use PATCH? You can use PATCH, or even POST, too. We haven't settled on a single best method to use, and in fact you'll notice different methods being used in different specs, depending on the personal preferences of the author that wrote that spec. :) I recommend checking out the Range Patch spec for more: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-range-patch-00 https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-r.... You'll see a lot of PATCH in there. :) Also, please feel free to start a discussion on the mailing list about this: ietf-http-wg@w3.org It's an issue that needs discussion and consensus more generally in HTTP.

Karrot_Kream 7y ago

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.

paulddraper 7y ago

> You could say it's non standard Isn't PATCH standard? What is non-standard about it?

sansnomme 7y ago
People don't use it and a lot of web frameworks don't have first class support for it. The main benefit is making the request more semantic. Idempotency etc. isn't always that useful on the protocol level so GET & POST is more than sufficient for most purposes.
BiteCode_dev 7y ago
PATCH became a standard in 2010 (https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789), I just never patched my brain with this new revision and had stale data.
- paulddraper 7y ago
  9 year max-age; impressive.

toomim 7y ago

> this seems to make HTTP stateful Yes -- depending on how you look at it. HTTP already has cookies to implement stateful sessions. Braid does add subscriptions; but HTTP 1.1 and 2 also has keep-alive at the TCP level: https://en.wikipedia.org/wiki/HTTP_persistent_connection https://en.wikipedia.org/wiki/HTTP_persistent_connection > It also uses PUT to patch things, but then why not use PATCH? You can use PATCH, or even POST, too. We haven't settled on a single best method to use, and in fact you'll notice different methods being used in different specs, depending on the personal preferences of the author that wrote that spec. :) I recommend checking out the Range Patch spec for more: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-range-patch-00 https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-r.... You'll see a lot of PATCH in there. :) Also, please feel free to start a discussion on the mailing list about this: ietf-http-wg@w3.org It's an issue that needs discussion and consensus more generally in HTTP.