Syncing local changes (originally: handle internet disconnect gracefully)
willprice opened this issue · comments
Set up:
- Vimflowy docker image: e532b43eb2f0
- SQlite storage backend
I host my own vimflowy server with the SQlite backend.
When I transition from being online to offline vimflowy encounters an error:
Socket connection closed!
g</t.prototype.init/</</this.ws.onclose@http://flametip.asuscomm.com:3000/build/app.js:46:117990
Which makes sense, the websocket connection to the server is closed. What'd be great is if Vimflowy transitions to local storage and then sync changes when it comes back online.
The more general case of conflict resolution of multiple edits using something like operational transforms or CRDTs is probably out of scope and overkill, a simple latest edit wins might be sufficient to implement the desired functionality
P.S cheers for Vimflowy, it's an awesome project merging two things I love!
this would be a nice feature, though I'm unlikely to implement it (sorry!). here are some thoughts on implementation anyways:
- latest edit wins doesn't seem like good behavior, IMO. I think better would be to create 2 subtrees for all problematic locations, and mark them with CONFLICT or something.
- if the only kind of sync is "fast-forward" you wouldn't need operational transform which would be nice. here's one way to "guarantee" that, though I don't know if it's a good UX. the server maintains a notion of which client owns the document. when you close the tab, the client first tells the server to relinquish ownership (i think this is possible?) - obviously when you go offline, you don't. a new tab can take ownership if nobody owns, otherwise there's a prompt like "Another document may be editing. Edit here? (changes there will be lost)"
Aside from this, there are other challenges and prerequisite changes. see #166 for a partial discussion. In general, I (perhaps regretfully), did not start this project with these sorts of considerations in mind and so things are perhaps a bit under-engineered. it's possible the changes wouldn't be too bad though, I just don't personally have the bandwidth for it
Fair enough Jeff, I completely understand lack of time ;) Thanks for taking the time to write up your thoughts on implementation, should I find myself with time to kill I might have a bash, although that sounds like a highly improbably situation.
Cheers