Skip to content
This repository was archived by the owner on Jul 23, 2019. It is now read-only.

Add support for running Xray in a web browser#67

Merged
as-cii merged 62 commits intomasterfrom
wasm
Apr 27, 2018
Merged

Add support for running Xray in a web browser#67
as-cii merged 62 commits intomasterfrom
wasm

Conversation

@nathansobo
Copy link
Copy Markdown

@nathansobo nathansobo commented Apr 26, 2018

xray_browser_2

This PR adds new subdirectories at the top level of the repo:

  • xray_browser Contains a WebPack configuration and a minimal entry point that packages Xray to be rendered in a web browser. It also contains a simple development web server that proxies web socket connections to a listening instance of xray_server.
  • xray_wasm A web-compatible counterpart to xray_server, which is the Rust core of Xray compiled to WebAssembly. It is designed to be run by xray_browser in a WebWorker, and can be thought of as an in-browser server.
  • xray_ui Xray's common user interface elements extracted from xray_electron to be shared betwen xray_electron and xray_browser.

To do before merging:

  • Figure out why proxied WebSockets are disconnecting from the development server (cae9261)
  • Allow the port of the development web server to be specified

@nathansobo nathansobo force-pushed the wasm branch 4 times, most recently from 618b4d5 to d895c1a Compare April 27, 2018 04:28
Antonio Scandurra and others added 26 commits April 26, 2018 22:31
Co-Authored-By: Nathan Sobo <nathan@github.com>
Co-Authored-By: Nathan Sobo <nathan@github.com>
This commit rearranges things a bit. We have a single Channel concept
with a sender and receiver that can be constructed from the JS side. In
addition, I introduce a JsSink concept, which can be constructed from JS
and implements the Sink trait on the Rust side. This allows Rust
functions to accept a Sink from JS and send the output of an arbitrary
stream to it. From the JS side we can handle the `send` and `close`
methods on the Sink trait with our own JS callbacks.

This commit also adjusts the executor to avoided repeated allocations of
a NotifyHandle Arc. We just allocate one Arc<NotifyHandle> per executor
now.
This makes room for adding a websocket listener.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Serializing PathBuf on a machine and deserializing it on a machine witha
different operating system is unsupported because of the way each OS
encodes its paths. With this commit we are introducing the
cross_platform module, which exposes a basic Path and PathComponent
structs that are able to encode OS-specific paths into a single data
type.

This type is then used in fs::Entry and other call sites to speak about
paths in a platform-agnostic way. Theoretically, after this commit, the
only call sites that don't use cross_platform::Path are those ones that
are platform-dependent (e.g., LocalProject::resolve_path) or where
platform doesn't matter (e.g., PathSearchResult::display_path).

Note also that we are only currently dealing with Unix paths, but this
abstraction should allow to handle Windows paths quite easily.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
We can open the file finder, but we panic when we confirm a selection.

Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
If polling a response *caused* a service to be created or destroyed, wewant to include that fact as part of the same update so we can reliablytake the created service on the client.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Nathan Sobo added 13 commits April 26, 2018 22:31
Running `npm install` keeps on breaking and this is the only way to fix
it. Frustrating.
It saves a bit of space but complicates the Travis build too much for
the being.
I can't find a way to effectively test the new context API yet with
enzyme, so we should just stick with the older version.
These random classes are impossible to write assertions against.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants