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.
The actual proxying is going to be tricky, too, for that matter.
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.
--
Most of the great triumphs and tragedies of history are caused not by
people being fundamentally good or fundamentally evil, but by people
being fundamentally people.
--Terry Pratchett
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
