On Sun, Jul 28, 2013 at 8:29 AM, Aryeh Gregor <a...@aryeh.name> wrote:
> 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. > Yes, there is the cost to initialize controllers each time (which is just unpredictable, as you'll be running arbitrary content script), and there is also cost to initialize the underlying worker and infrastructure every single time. Note that controllers sit between the web page and the network resources, and network latency is usually bad enough so you want to take care to not make it worse. But killing controllers after each request should be easy to implement as a debugging facility for times that authors want to debug their controllers, but I doubt that would be something we want to do by default. -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
