4 ms·
This looks really pretty but the protocol seems not to be well-thought-out from a cursory glance. The example itself shows a case where the non-owning nodes are
by 0xfffafaCrash 8y ago
This looks really pretty but the protocol seems not to be well-thought-out from a cursory glance. The example itself shows a case where the non-owning nodes are out of sync with the owner node (and sitting happily in a stable state!!!) and yet actions taken (possibly based off of the out-of-sync data...) are designed to propagate into mutations for the owned state which might be completely different to begin with! Instead of discarding alterations that are made on potentially bad/stale information, the system is designed to just accept any and all changes. There isn't even a rudimentary attempt at versioning to deal with conflicts and race conditions. Instead of dealing with errors from conflicts, they're swept under the rug and mutations are applied. Anything goes!
For a simple example of why that's a big problem imagine you have a state which has some boolean and an rcp that toggles that boolean which you fire based on that state (where both just want to turn it off). If two non-owning nodes say to toggle before the state has propagated from the other's change, it would turn off and back on again, cancelling each other out.
If this is just meant for toy projects where the worst case scenario has no real consequences that may be fine, but the polished look of the project is what's a little scary. It looks too professional for something that simply won't work.
- josemaenzo 8y agoThe protocol has a versioning system: https://github.com/DistributedObjectProtocol/protocol/blob/master/README.md#example-4 https://github.com/DistributedObjectProtocol/protocol/blob/m... Is the responsibility of the implementation to apply the patches/mutations in the correct order of the version.