4 ms·

I'm not keen that this extends HTTP instead of building on existing standards. Subscriptions, for instance, could simply be server sent events. Baking braid int

I'm not keen that this extends HTTP instead of building on existing standards. Subscriptions, for instance, could simply be server sent events. Baking braid into the protocol layer itself means it's harder to support it with existing libraries and code. I'm also a little unsure of why "partial PUTs" are needed. "PUT an update as a patch" seems like exactly the use case for PATCH. Not that it super matters either way as far as compatibility is concerned, but it feels like it's contorting PUT to do what PATCH already accomplishes

toomim 2y ago
See this comment on SSE: https://news.ycombinator.com/item?id=40482389 https://news.ycombinator.com/item?id=40482389 PATCH is supported in Braid, but only works for client->server. It does not support updates from server->client. So we need a way to express general updates, in both directions. Braid lets you use existing PATCH specs (as Patch-Type) if you want. The PATCH specification also confounds multiple concerns (versioning, conflicts, validation, data formatting, applicable data types) into a single spec. It's nicer for these aspects to be modular and independent. Partial PUT happens to be already a modular, independent way to specify just the patch format, and can be extended to new data types by "Range Units." But use PATCH if you prefer!
- bastawhiz 2y ago
  I don't feel especially strongly about the PUT vs PATCH distinction. But I left a comment on the thread you linked: I'm just not convinced there's a need for 209. Braid is trying to be both application logic and a transport protocol, but it doesn't have to be. SSE isn't perfect but all of the concerns around it could be addressed with relatively simple solutions.
  - toomim 2y ago
    I'm not convinced on 209, either. There might be a better response code. See the discussion at https://github.com/braid-org/braid-spec/issues/16 https://github.com/braid-org/braid-spec/issues/16 Braid is not trying to be "application logic" or "transport protocol" -- it is a State Synchronization Protocol. If you can think of a more elegant method to support all of state synchronization within SSE, we're all ears! But AFAICS you end up having to embed base64-encoded HTTP responses within SSE events within HTTP responses, which is gross pile of russian dolls, where both the innermost and outermost dolls are the same type of doll -- an HTTP response! So why all the intermediate dolls? It's more elegant and simpler to extend HTTP at the root level, and say: "Instead of returning 1 HTTP response, a Braid server can return N HTTP responses, concatenated together with optional newline separators."

toomim 2y ago

See this comment on SSE: https://news.ycombinator.com/item?id=40482389 https://news.ycombinator.com/item?id=40482389 PATCH is supported in Braid, but only works for client->server. It does not support updates from server->client. So we need a way to express general updates, in both directions. Braid lets you use existing PATCH specs (as Patch-Type) if you want. The PATCH specification also confounds multiple concerns (versioning, conflicts, validation, data formatting, applicable data types) into a single spec. It's nicer for these aspects to be modular and independent. Partial PUT happens to be already a modular, independent way to specify just the patch format, and can be extended to new data types by "Range Units." But use PATCH if you prefer!

bastawhiz 2y ago
I don't feel especially strongly about the PUT vs PATCH distinction. But I left a comment on the thread you linked: I'm just not convinced there's a need for 209. Braid is trying to be both application logic and a transport protocol, but it doesn't have to be. SSE isn't perfect but all of the concerns around it could be addressed with relatively simple solutions.
- toomim 2y ago
  I'm not convinced on 209, either. There might be a better response code. See the discussion at https://github.com/braid-org/braid-spec/issues/16 https://github.com/braid-org/braid-spec/issues/16 Braid is not trying to be "application logic" or "transport protocol" -- it is a State Synchronization Protocol. If you can think of a more elegant method to support all of state synchronization within SSE, we're all ears! But AFAICS you end up having to embed base64-encoded HTTP responses within SSE events within HTTP responses, which is gross pile of russian dolls, where both the innermost and outermost dolls are the same type of doll -- an HTTP response! So why all the intermediate dolls? It's more elegant and simpler to extend HTTP at the root level, and say: "Instead of returning 1 HTTP response, a Braid server can return N HTTP responses, concatenated together with optional newline separators."