Add protocol.registerStreamProtocol #507
Conversation
|
I've cleaned this up a little. Likewise I have no experience with C so I can't really comment on that code. It could do with some 👀 from the muon team (and possibly some alterations?). What's slightly bothering me atm is that the streaming works, but it doesn't support backpressure (notably neither does electron-ipc-stream). It means that if the destination starts saying "no more for now" we ignore it and keep pushing chunks through. I'm assuming that behind the scenes the extra chunks are buffered up until the destination is ready to receive again. Pending the outcome on that we probably need to decide if that is a blocker or not. I'd like to register my preference to not block so we can get this landed and so people can start trying it out! 🚢 As an FYI, streaming bit works like this: We need to stream data from the renderer process to the main process. To do this we create a "cross process through stream", which is writable on the renderer side and readable on the main process side. When data comes in to the writable side on the renderer, we use the IPC channel to pass it over the boundary. The readable on the other side picks it up and makes it available to whoever is reading it. In the renderer we're just attaching a 'data' event handler to the stream provided by the protocol handler and firing off an IPC message for each event. In the main process there's now a readable IPC stream which listens to the IPC messages and Some other concerns: We're sending chunks to the IPC channel in the order they arrive from the source stream. On the other side will they be fired as events in the same order? WE HAVE ASSUMED YES. We added the tests from the electron PR but I couldn't figure out how to run them. Am I correct in saying that the tests aren't currently runnable in muon? |
🚀 I have a feeling that implementing backpressure over an IPC channel might be difficult anyway.
olizilla
changed the title
| @@ -132,6 +116,22 @@ v8::Local<v8::Value> CreateFunctionFromTranslater( | |||
| v8::Object::New(isolate)); | |||
| } | |||
|
|
|||
| // func.bind(func, arg1). | |||
There was a problem hiding this comment.
does this have to move? It makes the change less clear
There was a problem hiding this comment.
@bridiver the move pulls it out of the unnamed namespace. It's used here https://github.com/brave/muon/pull/507/files/5c42c5d9755fef62518ae8a883e6ffb9aa8c20c4#diff-9e5169c80bbdb5c416b1d94cea1cf2ebR80
| @@ -0,0 +1,44 @@ | |||
| const Readable = require('stream').Readable | |||
There was a problem hiding this comment.
doesn't this file need to be added to the asar output in gn?
There was a problem hiding this comment.
I don't know enough about the build process to answer to that. We took the existing deep-equal local dependency used by extensions.js as our guide. There's no reference to deep-equal in a gn file, so assumed we didn't need to.
There was a problem hiding this comment.
sorry, I meant readable-ipc-stream.js, not require('stream')
There was a problem hiding this comment.
@bridiver yep, that's what i figured you meant. I was trying to say that we looked at the use site over in https://github.com/tableflip/muon/blob/5c42c5d9755fef62518ae8a883e6ffb9aa8c20c4/lib/browser/api/extensions.js#L3-L6 and followed the pattern that was used for deep-equal which we didn't find referenced in a gn file.
atom/browser/api/atom_api_protocol.h
Outdated
| @@ -93,6 +93,11 @@ class Protocol : public mate::TrackableObject<Protocol> { | |||
| net::URLRequestJob* MaybeCreateJob( | |||
| net::URLRequest* request, | |||
| net::NetworkDelegate* network_delegate) const override { | |||
| // hander not triggered if enabled. | |||
There was a problem hiding this comment.
Ah yes, that can go, it's just a left over from porting electron/electron#11008
| @@ -0,0 +1,206 @@ | |||
| // Copyright (c) 2017 GitHub, Inc. | |||
There was a problem hiding this comment.
can we make use of content::StreamURLRequestJob here?
There was a problem hiding this comment.
I don't know enough about the codebase to answer.
Ports
protocol.registerStreamProtocolfrom: electron/electron#11008To land cleanly, that changeset requires other upstream changes to be ported:
CallEmitWithArgsgeneralised toCallMethodWithArgsand it's signature changed to take the method name to call here: electron/electron@6d92457#diff-f7906bd787aa49d23220731778d7fa87Changed signature, to match the muon impl of
in: /electron/atom/common/native_mate_converters/net_converter.cc
The good news is that muon compiles with the ported changes, and using a fork of ipfs-companion I'm able to "stream" a response from ipfs via muon to brave.
I should qualify that I'm pretty good at spelunking around in codebases and porting things that look like they might work, but I have little C++ experience, so I'm offering this up as a starting point for discussion as a fix for brave/browser-laptop#10629
Also of note, I'd like to find a nicer way to stream the response over from the proxy impl ofprotocol.renderStreamProtocolin protocol_bindings.js, to the main process. I naively tried to use https://github.com/jprichardson/electron-ipc-stream but I'm not clear on the environment that the js in atom/common/resources/protocol_bindings.js is run in.Streaming works sensibly now thanks to @alanshaw