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
