I thought a little bit more about this after stepping away from my computer.
I think some of our implementation issues for service workers currently stems from the fact that the fetch spec and necko have modeled the problem with different primitives: - necko provides an object (nsIChannel) to represent the ongoing network request. The network request is described as parameters to the creation of the channel object. The response is defined as a series of callbacks on the nsIStreamListener interface. - In contrast, fetch defines object primitives for Request and Response, but has no explicit object to represent the on-going network request. These are both reasonable ways of doing things, but the impedance mismatch between the two makes it difficult to accurately translate the new specs into gecko. It might be nice to move the DOM code to use the Request/Response model to align things better with the spec. One approach we could take would be to add a new internal networking interface oriented around Request and Response objects. Internally it would still use nsIChannel, but would do all the work to translate to and from Request/Response. The DOM code would then be modified to create a Request, call this interface, and then process the returned Response. We already mostly have this interface in Fetch.h/FetchDriver.h, but we would probably need to adjust it a bit. For example, some of the referrer logic is handled in Fetch.h which requires the use of globals and Promises. In theory, though, we should be able to move this into FetchDriver and provide a clean internal interface to use. We could then start migrating consumers of NS_NewChannel() to the new FetchDriver interface. This would need to be done one-by-one and would probably run into problems with how to specify internal flags and stuff. It would be an incremental approach to use a Request/Response oriented model in the DOM code. I guess this is probably what you were originally suggesting and I was jumping to conclusions that you wanted to replace nsIChannel. Sorry for that. Anyway, what do people think? Ben On Fri, Jul 17, 2015 at 11:34 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Jul 17, 2015 at 5:26 PM, Benjamin Kelly <bke...@mozilla.com> > wrote: > > Do you have specific ideas about how you think things should be > refactored? > > Not really. I believe one of the things that came up was that Necko's > interface was not quite ideal and that most of this really ought to be > in Necko instead, but I can't really speak to the code. I'd just like > us to think about this since our architecture seems quite prone to > serious security bugs. > > > > I think the only realistic thing we can do is make nsIChannel work more > like > > the fetch spec over time. > > > > Of course, the main problem will be that we have to support backward > compat > > in places the spec might be able to say its making a breaking change > > compared to the wild web. > > If you come across a specification that does that it's a bug in the > specification. That's not acceptable. If you noticed cases like that > in Fetch I would very much like to remove them. > > If you extend compatibility to add-ons though I can understand that > refactoring here might get tricky, but hopefully our new add-ons > efforts can help with that transition? > > > -- > https://annevankesteren.nl/ > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
