On 1/4/16 6:29 PM, Kris Maglione wrote:
On Mon, Jan 04, 2016 at 08:27:59PM -0500, Jason Duell wrote:
In the child we hand out a stub channel (HttpChannelChild) that looks
and smells like an nsIHttpChannel, but actually uses IPDL (our C++
cross-platform messaging language) to essentially shunt all the real
work to the parent. When AsyncOpen is called on the child, the stub
channel winds up telling the parent to create a regular "real" http
channel, which does the actual work of creating/sending an HTTP
request, and as the reply come back, sending the data to the child,
which dispatches OnStart/OnData/OnStopRequest messages as they arrive
from the parent.
...
From talking to folks who know JS better than I do, it sounds like the
mechanism you'll want to use for all your cross-process communication
is the Message Manager
I think that doing this in an add-on is asking for trouble. I don't
think I've ever seen nsIChannel implemented in JavaScript. It might
work, but I'd be surprised if it didn't break in very strange ways. Even
if it works perfectly, though, it's not going to be fun to maintain.
OverbiteFF implements a Gopher channel object which is, indeed, an
nsIChannel. It does have proxy support. Worked pretty well up until now
... ;)
If you can implement the protocol handler purely in the content process,
you're going to have a much better time.
If you can't, I think your best bet would probably be to use an input
stream channel in the child, and only proxy the nsIStreamListener
callbacks from the parent to the child (ideally by sending messages
containing ArrayBuffers, using readArrayBuffer and
nsIArrayBufferInputStream). That's pretty close to how most protocols in
add-ons are implemented anyway.
This is what I'm considering, though the channel implementation is not
fully clean and does some front-end manipulation as well (for example,
it adds a notification box to the tab with the current gopher URL, so it
needs to iterate over open tabs to find the right one). It also has
getters and setters for the load group and notification callbacks, and
uses the thread manager to get the current thread to use as an event
sink for the socket. Would all this work in the child process?
Cameron Kaiser
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform