Last week we completed the initial milestone for shared workspaces, which allows you to connect to a remote Xray instance over TCP and open one of its workspaces in a new window. You can then use the file-finder to locate and open any file in the remote project and collaboratively edit buffers.
There is obviously a ton more work to do until we can call our implementation of shared workspaces "done". Xray isn't even really usable right now for even basic text editing due to a long tail of missing features. Regardless, we think it's really important to have this infrastructure in place early. From here on out, every feature we build will be designed to support remote collaboration, and the foundation we've laid over the last two weeks will make that possible. We're pretty excited about the potential RPC system we've built. By combining remote procedure calls with eagerly replicated state and the judicious use of conflict-free replicated data types, we think we can abstract away the physical boundaries that separate individual machines and developers.
The four pillars of Xray are performance, real-time collaboration, browser compatibility, and extensibility. 8 weeks into focused development, we're feeling confident that Xray's architecture can meet our desired performance goals, and we've validated an approach that will bake collaboration into the heart of the system. Before burning down the long list of features that make up a usable text editor, we want to take some time to put the last two pillars in place by getting Xray working in a browser and laying the foundation for extensibility. By taking care of all four of these high-level concerns early, we'll ensure that they're supported as we build out the remainder of the system.
To that end, we're now turning our attention to browser compatibility. We've actually been designing Xray with this goal in mind from the beginning. Today, Xray comprises two major components: xray_server, which contains the core application logic, and xray_electron, which presents the user interface and communicates with xray_server over a local socket. Now we need to create versions of these two components that run inside of a web browser.
As a browser-based counterpart of the xray_server executable, we're creating xray_wasm, which will be compiled to WebAssembly and run in a web worker. xray_wasm will share the majority of its implementation with xray_server via a dependency on the platform-agnostic xray_core crate. xray_core abstracts its communication with the outside world in terms of abstract traits defined by the Rust futures crate. Methods for connecting to remote peers and the user interface accept and return Streams of binary buffers, and the application also expects to be passed Executor instances that can schedule futures to be executed in the foreground or background.
In the browser, we'll move data via message channels and web sockets rather than using domain sockets and TCP, but these are just transport layers and are easy to abstract in terms of Streams and Sinks so they can be passed into the platform-agnostic code. Similarly, we'll integrate with the browser's event loop by writing a custom Executor that uses the Promise API or requestIdleCallback to defer computation.
We're using the wasm-bindgen crate to interoperate between Rust and JavaScript, and last Friday we managed to get asynchronous bi-directional communication working between Rust and JavaScript. This week, we plan to extract as much UI code as possible from xray_electron into a common library called xray_web. We'll then create xray_browser, which will package everything together into a browser-deployable bundle that runs the core application logic in a web worker and connects it to the UI running on a web page.
Since browsers strongly sandbox interaction with the underlying machine, we will only support interactions with remote shared workspaces when Xray is running in a browser. We plan to add WebSockets support to Xray server so that it can accept connections from browser-based clients. We'll also add an --http option that exposes a simple web server from xray_server that serves a browser-based UI to clients. This will obviously require a security scheme to be useful in a production setting, but it seems like a good way to develop the browser-based user experience. A simple password-list based security scheme would also be pretty quick to add.