问题
目前支持从web到Codespaces,从桌面到vscode.dev,从桌面到Codespaces的继续工作。这通过在查询参数中传播编辑会话标识符(一个guid)并将其传递到工作台创建选项中来实现。
我们现在也希望在web到桌面，桌面到桌面等场景中支持继续工作。这将使我们能够与现有的继续工作体验实现完全的功能对等，以及能够随身携带未提交的更改。以下是需要支持的现有场景：
- github.dev -> 本地克隆
- RemoteHub桌面 -> 本地克隆
- RemoteHub桌面 -> 在容器卷(远程容器)中克隆
为了实现这一点，我们有几个选择：
- 将编辑会话标识符传播到所有桌面入口点，即
- 扩展的协议处理程序(web -> 桌面)
vscode.openFolder命令参数(桌面 -> 桌面)- 这具有非常明确地确定哪个编辑会话应该与当前工作区关联的优势
- 使VS Code能够确定相关的编辑会话标识符
- 最终，编辑会话是一个不透明的JSON对象，包含一些要应用于特定VS Code状态的数据
- 我们希望与此数据关联足够的元数据，以便我们不会应用错误的状态
- 此处的相关状态是仓库标识
- 作为初始客户，此API应由Remote Repositories和内置的git扩展实现
- 此API最终也将需要启用您永远不会丢失RemoteHub更改的场景，即编辑会话在没有显式调用存储命令或继续工作命令的情况下保存，并且它们在没有显式调用恢复的情况下自动恢复。这是一个复杂的场景，我们不想立即实现它
- 这个提案让我们更有信心认为最新的编辑会话与当前工作区相关联，而无需在我们的应用中引入更多的编辑会话标识符(最终可能允许我们摆脱我们在web嵌入器情况下对查询参数方法的依赖)。它还可能提高编辑会话恢复机制的可靠性，因为我们不受像嵌入器丢弃查询参数导致编辑会话关联丢失这样的 transient 故障的影响。例如
2条答案
按热度按时间exdqitrt1#
@TylerLeonhardt还提议我们可以使用这个API来消除不同机器上克隆的仓库之间的歧义，这样用户只需要在他们所有相同仓库的克隆中信任一次给定的仓库。
s4n0splo2#
今天，我和@jrieken@bpasero讨论了这个API提案，因为我们在正常的API调用中时间用完了。主要的反馈是：
EditSessionIdentity更名为WorkspaceSessionIdentifier或类似名称file方案的工作区只能有一个有效的提供者，但最终可能会出现给定的工作区可能有多个提供者的情况，例如，如果它备份到多个远程托管服务。在这种情况下：autoStore设置可能会对用户体验产生影响，因为在窗口卸载之前与云服务通信可能是长时间运行的