On Fri, Jul 26, 2013 at 8:29 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > We're planning to implement a prototype of the NavigationController > interface (see bug 898524). We will try to get feedback from web > developers on the prototype and will use that feedback to change the spec > and the implementation and iterate on the API. Our major goal for now is > coming up with a good API that is useful for the intended use cases. Once > we're there, we will talk about plans to ship the API. For now, all of > this work will be disabled for web content. > > Please let me know if you have any questions!
One question I have after reading over the draft: "This simply can't be stressed enough: write your controllers as though they expect to die after every request, only to be revived for the next one." Why not actually do this, for predictability's sake? As we know, one of the big things that trips up web compat is when some key bit of behavior is left unspecified and different browsers implement it differently -- e.g., one browser might decide to keep the same instances around as long as the browser is open, and another to restart it often (maybe every request). Someone who writes a controller for the first browser is likely to find it won't work in the second. Are there any performance issues that might occur if the script has to be re-run for every request? These scripts don't look like they need to do much work in normal cases, so rerunning them shouldn't hurt performance much, I would think. And it shouldn't be hard for authors to figure out ways to cache complicated state, if it is actually a performance bottleneck. Authors of server-side script are quite accustomed to this already. It's very likely that I'm just missing something. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
