-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Articulate the general form of Updates #118
Comments
For Question 2, I'm copying the pros/cons of "Requiring
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #96 we realized that the Braid-HTTP illustrates a range of ways to express Updates (aka "New Version" messages), but doesn't fully articulate the general form. This results in a lot of confusing ambiguity about what the spec allows.
I propose writing up a general form for Updates:
This should satisfy the questions raised in issue #96, and ensure we have symmetry across range requests and responses in the design under consideration in #97 (comment).
Finally, once we articulate the general space of possible updates, we also noted in #96 (comment) that we might want to impose some constraints on this general form in practice, so we should deliberate what those might be, and articulate any that we want to impose.
Open Questions:
Patches: 1
in subscription responses as mentioned in issue 97, that might simplify implementations?The text was updated successfully, but these errors were encountered: