We're going to want IPDL state checking for PHttpChannel sooner or later, since it will verify that we can't get into any wedged or inconsistent states that we might overlook otherwise. It will also give us a state member variable that we can check and base other things on (such as the legality of the various "SetFoo" operations, which should often only be legal before AsyncOpen is called). Right now I've added an 'mState' variable to do that job: when IPDL states are working, it should be removed. My impression is that once you start implementing IPDL states, you've got to get them "right" immediately, or the IPDL compilation will fail (cjones, true?). So this may be something that's easier to do once we have a richer picture of what our message traffic and states look like, for instance, once we've got notifications, redirects, and cancel working. But it may also be useful and not too hard to implement something sooner, and add onto it. I'm not sure of the exact development trajectory here. My gut sense is it's easy to add the features now, and unless we find we need the IPDL checks to solve bugs, add IPDL state checking later. We might also run into nontrivial hg merge issues if we have different people tweaking the IPDL state transitions as they work on different aspects of HTTP--another reason to perhaps hold off for now.

(In reply to comment #0) > My impression is that once you start implementing IPDL states, you've got to > get them "right" immediately, or the IPDL compilation will fail (cjones, > true?). Yes. > So this may be something that's easier to do once we have a richer > picture of what our message traffic and states look like, for instance, once > we've got notifications, redirects, and cancel working. I'd recommend writing the protocol as you go, even if you keep it commented out in hg for "a while" You'll derive documentation/think time benefits, and additionally can flag bugs/lacking features in the IPDL compiler that can be fixed in parallel.

Now that e10s buffers IPDL traffic, IPDL states aren't useful.

I strongly disagree with wontfixing this. The end goal is that all asynchronous protocols must be stateful. It's not a moz2 blocker, though.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258