Switch to a client/server architecture

[nathansobo]

As discussed in the update for March 12, we are switching Xray to a client/server architecture that places as much logic as possible in a central server process. This PR is the implementation of that plan.

I'm including a detailed explanation of the contents of this PR in a markdown document that will become a permanent part of our documentation once this is merged. Hopefully it's high-level enough that we have a reasonable chance of keeping it updated.

Tasks

• Get basic window-launching flow working
• Send view updates to the client
• Send actions to the server
• Clean up documentation
• Address double borrow when dropping ViewHandles
• Eliminate remaining compiler warnings

@cmyr, since you were interested in any PRs related to our approach to the client/server protocol, I'm cc'ing you on this PR.

[lucat1]

I would like to test the new architecture, but I get stuck at building the napi module via the scripts/napi.js script. Could you provide any build instructions for the new setup? Maybe in the README.

BTW here' the error I get when running the script:

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
cp: ../target/debug/libnapi.dylib: No such file or directory
child_process.js:614
    throw err;
    ^
Error: Command failed: cp ../target/debug/libnapi.dylib target/debug/napi.node

at checkExecSyncError (child_process.js:574:11)

at Object.execSync (child_process.js:611:13)

at Object. (/Users/luca/projects/xray/napi/scripts/napi.js:55:8)

at Module._compile (module.js:660:30)

at Object.Module._extensions..js (module.js:671:10)

at Module.load (module.js:573:32)

at tryModuleLoad (module.js:513:12)

at Function.Module._load (module.js:505:3)

at Function.Module.runMain (module.js:701:10)

at startup (bootstrap_node.js:190:16)

After a quick debug I've noticed that the script isn't generating the .dylib file, that it should: https://github.com/atom/xray/blob/master/napi/scripts/napi.js

[alexandernst]

A wild idea: Would it be possible to completely split client from server (two different binaries) and make them do IPC via socket (only when required, for performance reasons).

If that is possible, then I think it would be possible to install Atom-server on a remote machine (let's say a production server without X) and Atom-client on a local machine (let's say developer's machine, like for example random John Doe that shouldn't be editing files remotely on the production server).

[nathansobo]

@alexandernst We are completely separating the client from the server in this PR as you describe, but the server needs to be running locally for there to be acceptable latencies. We do intend to enable server to server communication to enable the kind of experience you're describing, but we can't just connect the view directly to a remote server without unacceptable lag in the UX.

[NachE]

This sounds like a 21st century Xfree. Do you expect good latency using client/server architecture?

[nathansobo]

@NachE if the server is local as we’re currently designing this then yes, latency should be minimal. Communications with a remote server will be routed through the local server and use CRDTs to avoid latency where it would be problematic.

[jasonrudolph]

s/in inspired by/is inspired by

[nathansobo]

🙇

[nathansobo]

We've changed the roadmap on this PR a bit to cut scope. Previously, we were thinking of including the file finder experience as part of this PR. Thinking about the file finder was useful in driving out the design of our window / views abstraction, and we made decent progress toward implementing it, but we've decided to drop it from this PR for now and just render an example editor. That gets us back to parity with master. We should be able to merge this week, and then we can pick up the file finder work on another branch.