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
Changeset Inverses Brain Dump Doc #11484
Conversation
|
TODOs:
|
| peers need to have access to the following as far back as the collaboration window extends: | ||
| * Changes and their associated repair data | ||
|
|
||
| #### Data Communication Needs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this section should indicate that it is be possible to implement a design where peers sometimes or always have the results of these queries cached locally, especially in the case where there is a bound on how old the target of an undo can be. I think we would like to support systems which want to fully process all incoming changes synchronously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you thinking of an approach where the changeset sent by the issuing client would not contain the repair data but instead contain some characterization of it, which peers would then be able to fill out? If so, do think of that as something different than what is described in the "Late Repair Data Concretization" section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the guaranteed synchronous design, it could be what's described in Late Repair Data Concretization. I don't have a specific design proposal, but I think it would be nice if (assuming we're not sending all repair data inline) we always sent the references to the repair information in a format that makes it easy both to craft queries to a service and to find the information locally if it exists. Just sending a URL to a blob with all the repair data, for example, would not meet the criteria I'm proposing, because peers which had the relevant repair data available locally would probably not be able to convert that URL into a query on their local data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a "Abstract Repair Data Description" section here. I agree it's good to call out here. Documentation should favor clarity at the risk of redundancy.
Co-authored-by: alex-pardes <105307164+alex-pardes@users.noreply.github.com>
|
This commit is queued for merging with the |
Adds a document containing a brain dump on inverse changes and undo.