4 ms·

I was thinking about this the other day and realised the rsync algorithm should be feasible to compile to javascript to provide a sporadic, byte-efficient synch

I was thinking about this the other day and realised the rsync algorithm should be feasible to compile to javascript to provide a sporadic, byte-efficient synchronization system with smart polling fallbacks in the case of zero websockets without the need for polling, websockets or JSON-based diffing protocols.

dboreham 6y ago
https://github.com/ttezel/anchor https://github.com/ttezel/anchor https://webdeltasync.github.io/ https://webdeltasync.github.io/
- contingencies 6y ago
  Yeah. So someone's done a reimplementation (vs. cross-compile webasm style), but it only has 135 stars (first case) and 10 (second case). Just shared the first one as an HN link at https://news.ycombinator.com/item?id=25405094 https://news.ycombinator.com/item?id=25405094 ... let's see if people upvote it or do something useful with it...
SahAssar 6y ago
The problem as I've understood it is conflict resolution, not diffing. Rsync only does one-way sync so it does not help much here.
- contingencies 6y ago
  I guess you can have a distributed locking mechanism, either scope or line-driven. Another option would be when there is a conflict you have a fork, and then re-merge at a later point (eg. when scope-specific changes are complete or scope is left or syntax is re-evaluated as valid), more similar to git style workflow. Which begs the question, why not just use an established RCS/VCS like git and build the interface in front of it, utilizing its built-in diff? However, this workflow probably detracts greatly from the real time intent...
  - SahAssar 6y ago
    > I guess you can have a distributed locking mechanism, either scope or line-driven In real time? How would that solve the problems outlined in the article? > However, this workflow probably detracts greatly from the real time intent Seems like you understand the problem.
  - monroewalker 6y ago
    *raises the question https://en.wikipedia.org/wiki/Begging_the_question https://en.wikipedia.org/wiki/Begging_the_question

dboreham 6y ago

https://github.com/ttezel/anchor https://github.com/ttezel/anchor https://webdeltasync.github.io/ https://webdeltasync.github.io/

contingencies 6y ago
Yeah. So someone's done a reimplementation (vs. cross-compile webasm style), but it only has 135 stars (first case) and 10 (second case). Just shared the first one as an HN link at https://news.ycombinator.com/item?id=25405094 https://news.ycombinator.com/item?id=25405094 ... let's see if people upvote it or do something useful with it...

SahAssar 6y ago

The problem as I've understood it is conflict resolution, not diffing. Rsync only does one-way sync so it does not help much here.

contingencies 6y ago
I guess you can have a distributed locking mechanism, either scope or line-driven. Another option would be when there is a conflict you have a fork, and then re-merge at a later point (eg. when scope-specific changes are complete or scope is left or syntax is re-evaluated as valid), more similar to git style workflow. Which begs the question, why not just use an established RCS/VCS like git and build the interface in front of it, utilizing its built-in diff? However, this workflow probably detracts greatly from the real time intent...
- SahAssar 6y ago
  > I guess you can have a distributed locking mechanism, either scope or line-driven In real time? How would that solve the problems outlined in the article? > However, this workflow probably detracts greatly from the real time intent Seems like you understand the problem.
- monroewalker 6y ago
  *raises the question https://en.wikipedia.org/wiki/Begging_the_question https://en.wikipedia.org/wiki/Begging_the_question