4 ms·

> 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

by 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
    Yes, the question is whether to make it a standard.
- toomim 7y ago
  Thank you very much! Does EventSource meet your need for a generic subscribe mechanism? https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource I'm also curious what use-cases you have for a generic pub/sub beyond synchronization. In my experience, 95% of pub/sub implementations are used as a substrate for synchronization. As for using PATCH vs PUT, this is an open question. I'd love to see more discussion of it on the mailing list: ietf-http-wg@w3.org. There are a number of pros and cons on both sides.
  - BiteCode_dev 7y ago
    EventSource is only from the server to the client. Pub/sub goes in any direction: client to client, client to server, etc. Crossbar.io provides that with websocket. Eventsource + the sync rfc would mean everybody would build a non standard bridge for this to link a publication, a sync from the server and an event source. And because we only need 2, and they are overlapping, several completly incompatible de facto solutions would emerge. Pub/sub is useful for any kind of communication that doesn't involve a resource: notifications of events , communication between microservices, etc. Basically anything that doesn't have a need for an history. Of course, you can always create abstract conceptual resources you sync with to obtain this effect. E.G: the "streaming service is down event" could be a sub to a "service/streaming/heartbeat" event that you sync, and ignore versions and give no parents. It's just a bit twisted. It feels more natural to have a pub/sub primitive that goes back and forth in any direction, and build the specific case for sync with that. Even if sync is 90% of the time what you want.

by toomim 7y ago

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
  Yes, the question is whether to make it a standard.
toomim 7y ago
Thank you very much! Does EventSource meet your need for a generic subscribe mechanism? https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource I'm also curious what use-cases you have for a generic pub/sub beyond synchronization. In my experience, 95% of pub/sub implementations are used as a substrate for synchronization. As for using PATCH vs PUT, this is an open question. I'd love to see more discussion of it on the mailing list: ietf-http-wg@w3.org. There are a number of pros and cons on both sides.
- BiteCode_dev 7y ago
  EventSource is only from the server to the client. Pub/sub goes in any direction: client to client, client to server, etc. Crossbar.io provides that with websocket. Eventsource + the sync rfc would mean everybody would build a non standard bridge for this to link a publication, a sync from the server and an event source. And because we only need 2, and they are overlapping, several completly incompatible de facto solutions would emerge. Pub/sub is useful for any kind of communication that doesn't involve a resource: notifications of events , communication between microservices, etc. Basically anything that doesn't have a need for an history. Of course, you can always create abstract conceptual resources you sync with to obtain this effect. E.G: the "streaming service is down event" could be a sub to a "service/streaming/heartbeat" event that you sync, and ignore versions and give no parents. It's just a bit twisted. It feels more natural to have a pub/sub primitive that goes back and forth in any direction, and build the specific case for sync with that. Even if sync is 90% of the time what you want.