This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
Inform guest of all available editors when joining, and update list as host adds/removes editors #52
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Antonio Scandurra <as-cii@github.com>
This object is a summary of an `EditorProxy` object and will be useful for plugins like a fuzzy finder, where we want to know which editors the host workspace contains without necessarily downloading their buffers and histories.
With this method we will now explicitly track all the editor proxies that are added to the host's workspace. This is symmetric to `removeEditorProxy`, whose job is to signal when an editor is removed from the host's workspace. Note also that the portal delegate methods `addEditorProxy` and `removeEditorProxy` now take a metadata parameter instead of an entire editor proxy object.
jasonrudolph
changed the title
This was referenced Feb 9, 2018
Merged
Instead, every time a new editor proxy is created we will broadcast its metadata to all the guests. Removing an editor proxy from the portal is not needed either because we already notify guests when an editor proxy is disposed. With this commit we are also introducing two new methods: * `didChangeEditorProxies` on guest portal delegates, which will be called every time an editor proxy is created or destroyed. * `getEditorProxiesMetadata` on Portal, which will return an array containing the metadata for all the editor proxies that are still alive in the portal.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In conjunction with atom/teletype#323 and atom/fuzzy-finder#335, this pull request implements the necessary teletype-client changes to deliver the following functionality for atom/teletype#268:
Description of the Change
Prior to this change, when a guest joined a portal, the host only sent the guest information about the host's currently-active editor. To access other editors in the portal, the guest had to wait for the host to focus those other editors, and the guest had to be following the host when the host switched to a new editor.
With the changes in this pull request, when a guest joins a portal, the host will now send the guest a list of metadata for all the buffers in the workspace. Similarly, each time the host adds a new editor to their workspace, the host will send the metadata for that editor to all guests, regardless of whether the guests are actively following the host. Because the guests will have a list of all available editors in the portal, guests will be able to browse the list of available editors and choose which ones they want to open.
Alternate Designs
When a guest joins a portal, instead of sending a list of metadata for each editor in the portal, the host could send the complete
EditorProxydata for each editor in the portal. With this approach, when a guest wants to open an editor, they would already have the editor's content, and they wouldn't have to make a separate request to the host to fetch the editor's content. As a result, the guest would likely be able to open a remote editor faster.However, this approach would likely cause a significant slow-down in the process of joining a portal. The host would have to serialize the full history of every editor in the workspace (potentially a large list of editors, potentially with a large amount of content in those editors, potentially with a large history for those editors), and all of that data would need to travel across the network from the host to the guest, and then the guest would have to deserialize all that content, regardless of whether the guest wanted to open all of those editors. Instead, this pull request has the guest fetch the full data for a remote editor on demand, only when/if the guest chooses to open a particular remote editor.
TODO
addEditorProxyandremoveEditorProxy🍐'ed with @as-cii