You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, first I'd like to say thanks for these tools! I've played around with them some and they seem to work well for collaborating on text-based documents.
VSC offers the ability to work with certain kinds of files that are text-based on disk, but edited through some other type of interface. For example, built-in jupyter notebooks and this awesome excalidraw extension. These both work by making small edits to an underlying JSON file.
From what I've experimented with OCT in VSC, opening text-based files with other UIs on both ends works fine. The issue (in the case of the excalidraw for instance) is that when one end makes a change the file gets synced correctly, however the other end who received the file changes would not see the drawing update (if they also had the drawing open at the same time). In order to see the updated drawing, they'd need to close out of it and re-open. Otherwise, if they made a change to the drawing without reopening it, they would end up clobbering the incoming change.
All of this behavior would be what I'd expect to happen without some kind of handling around two parties editing the file at the same time. I think one minimalist approach to this would be to introduce a feature for a person to (request to) acquire a lock around a file (or potentially entire folder), such that the other collaborators can only have read-access.
The text was updated successfully, but these errors were encountered:
first I'd like to say thanks for these tools! I've played around with them some and they seem to work well for collaborating on text-based documents.
Thank you, we appreciate it :)
we're actually planning to look into notebook collaboration soon. Everything that we need for that is exposed by the VS Code API, it just needs some implementation work.
Collaborating on stuff via extensions (like excalidraw) is a bit more difficult, since it actually only compatible with the original vscode-liveshare extension. We'll need to see whether we're able to provide an alternative API layer to that or to somehow hack into the VSCode extension host so we can redirect calls to the vscode-liveshare extension to our own VSCode extension. Either way, it's not obvious how that should be done.
All of this behavior would be what I'd expect to happen without some kind of handling around two parties editing the file at the same time. I think one minimalist approach to this would be to introduce a feature for a person to (request to) acquire a lock around a file (or potentially entire folder), such that the other collaborators can only have read-access.
I'm not sure how feasible this is to implement from the VSCode API level, but I'll take a look at that soon.
Hello, first I'd like to say thanks for these tools! I've played around with them some and they seem to work well for collaborating on text-based documents.
VSC offers the ability to work with certain kinds of files that are text-based on disk, but edited through some other type of interface. For example, built-in jupyter notebooks and this awesome excalidraw extension. These both work by making small edits to an underlying JSON file.
From what I've experimented with OCT in VSC, opening text-based files with other UIs on both ends works fine. The issue (in the case of the excalidraw for instance) is that when one end makes a change the file gets synced correctly, however the other end who received the file changes would not see the drawing update (if they also had the drawing open at the same time). In order to see the updated drawing, they'd need to close out of it and re-open. Otherwise, if they made a change to the drawing without reopening it, they would end up clobbering the incoming change.
All of this behavior would be what I'd expect to happen without some kind of handling around two parties editing the file at the same time. I think one minimalist approach to this would be to introduce a feature for a person to (request to) acquire a lock around a file (or potentially entire folder), such that the other collaborators can only have read-access.
The text was updated successfully, but these errors were encountered: