mirrors/zed
1
0
Fork 0
mirror of https://github.com/zed-industries/zed.git synced 2025-01-22 09:59:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 12

Add document outlining plans for collaboration

Browse source 
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This commit is contained in:
Max Brunsfeld 2021-05-31 15:31:57 -07:00
parent 3597305fe3
commit a4d16e61c8
1 changed files with 56 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
docs/collaboration-v1-plan.md Normal file
View file

@ -0,0 +1,56 @@
# Collaboration V1
### Sharing UI
* For each worktree that I edit in Zed, there is a *Share* button that I can click to turn *sharing*
on or off for that worktree.
* For each worktree that I share, Zed shows me a URL that I can give to others to let them
collaboratively edit that worktree.
* __Question__ - Does the sharing on/off state of each worktree persist across application restart?
When I close Zed while sharing a worktree, should I resume sharing when I reopen Zed?
Pros:
* This would remove friction from teams collaborating continuously.
Cons:
* I might have added something secret to the worktree since I last opened Zed. Could we detect
changes that have occured outside of Zed, and avoid auto-sharing on startup when that has
happened?
### Sharing Semantics
* While sharing, the entire state of my worktree is replicated and stored forever on the Zed server.
Other collaborators can freely read the last state of my worktree, even after I've quit Zed.
* __Potential Scope Cut__ - For now, we won't store the history locally, as this isn't needed for
collaboration. Later, we may explore keeping a partial history locally as well, to support using
the history while offline. A local history would allow:
* Undo after re-opening a buffer.
* Avoiding redundant uploads when re-opening a buffer while sharing.
* When I begin sharing:
* Immediately, I upload a list of all the paths in my worktree, along a digest of each path
* The server responds with a list of paths that needs
* First, I upload the contents of all of my open buffers.
* At this point, sharing has begun. I am shown a URL.
* Asynchronously, I upload the contents of all other files in my worktree that the server needs.
* While I'm sharing:
* Buffer operations are streamed to the Zed server, and to any peers that I'm collaborating with.
* When FS changes are detected to files that I *don't* have open:
* I again upload to the server a list of the paths that changed and their new digests.
* The server responds with a list of paths that it needs
* Asynchronously, I upload the new contents of these paths.
* If a peer requests to open one of my files that I haven't yet asynchronously uploaded, then
the server tells me to upload the contents of that file immediately.
* When I stop sharing:
* I immediately stop uploading anything to the Zed server.
* __Question__ - If, while sharing, I undo an operation that I performed while *not* sharing, what
information do I need to send to the server?
* Can we transmit the operation as a new `Edit`, instead of as an `Undo`, so that the server can see
the details of the operation? Will this be guaranteed to converge, since there can't have been any
operations concurrent with the undone operation?
### Further Improvements
* When we add a local persisten history of our worktree, we will be able to
avoid uploading entire snapshots of files that have changes since our last sharing session.
Instead, the server can report that last version vector that it has seen for a file,
and we can use that to construct a diff based on our history.