Remote Development Tool Extension Execution via Segmented Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software development tools face challenges in providing remote development support without requiring significant changes to existing extensions, especially when dealing with large projects that span multiple machines with different filesystems and processing environments.
Innovation Solution
A development tool architecture that separates the user interface renderer on a developer machine from the extension host and extensions on a remote extension machine, using uniform resource identifiers for file identification and process spawning to enable efficient remote execution without sharing filesystems or processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If development tool extensions are executed locally on a single machine, then file system access and process spawning are simple and direct, but remote development support and multi-machine collaboration are limited
Solution Approach 1:
The development tool is segmented into two distinct components running on separate machines: a renderer process on the developer's machine that handles UI rendering and user input, and an extension host process on the remote machine that executes extensions and accesses the file system. This segmentation enables remote development support while maintaining clear boundaries between components.
Solution Approach 2:
A message passing mechanism serves as an intermediary between the renderer and extension host, transmitting requests and responses across the network. This intermediary layer abstracts the complexity of remote communication, allowing extensions to operate remotely without requiring direct file system access or process spawning on the developer's machine.
2Reliability
If a single shared file system is used across all machines, then file access is straightforward and fast, but security concerns and filesystem compatibility issues arise
Solution Approach 1:
Each machine maintains its own local file system with distinct characteristics and security contexts. The extension host on the remote machine accesses files through its local file system, while the renderer on the developer's machine interacts with files through standardized paths. This approach preserves local file system integrity and security while enabling cross-machine collaboration.
Solution Approach 2:
The message passing mechanism acts as an intermediary that translates between the developer's machine file paths and the remote machine's file system paths. This abstraction layer handles path mapping and file access coordination, maintaining security boundaries while enabling efficient file access across machines.
3Adaptability or versatility
If all processes are spawned on the same machine as the extension, then process management is simple and fast, but remote process execution and distributed computing capabilities are lost
Solution Approach 1:
The message passing mechanism enables process spawning on the remote machine by transmitting process creation requests from the renderer through the extension host to the appropriate process manager. This intermediary approach maintains process management simplicity while enabling distributed process execution across multiple machines.
Solution Approach 2:
Process management functionality is segmented and assigned to the extension host on the remote machine, separate from the renderer on the developer's machine. This segmentation allows processes to be spawned and managed on the remote machine where the extensions execute, enabling distributed computing while keeping process management logic centralized in the extension host.
Data Source
Figure 1~3
Figure 4~6
Figure 7~9
AI summary
Enhancements described support transparent remote execution of development tool extensions. Compute-intensive extensions may be executed on an extension machine external to a developer machine which runs a user interface renderer of the development tool. User interface extensions may run locally. Instead of sharing a filesystem, the renderer on the developer machine and an extension host and extension(s) on the extension machine may access distinct respective machine filesystems. Instead of spawning debug extension and other extension-support processes locally, the renderer may instruct the extension host or an extension host agent to spawn the processes remotely on the extension machine. No change is needed to extensions; existing extensions and newly created extensions are binary-compatible with single-machine or multi-machine development tool deployments. Project files remain inside a firewalled and data-loss-prevention environment while nonetheless being fully accessible to authorized developers working remotely and to operations performed by language servers, debug adapters, and tool extensions.