Re: Intent to implement: NavigationController
On 08/08/13 23:52, Ehsan Akhgari wrote: I think you forgot the bug number. :-) Ehsan: any chance you could trim your responses? I had to page-down 9 times in my mail client just to read this one line... Thanks :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Thu, Aug 8, 2013 at 7:50 PM, Nikhil Marathe nsm.nik...@gmail.com wrote: There is no bug number yet, because I have about 15 lines of additional code :) There is now! https://bugzilla.mozilla.org/show_bug.cgi?id=903441 -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote: On Mon, Aug 5, 2013 at 3:17 PM, Nikhil Marathe wrote: On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote: On 26/07/13 18:29, Ehsan Akhgari 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! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir I'm experimenting with this. The SharedWorker patches are crucial to this, and I've spent some time trying to get them to work on m-c, before I can start working on this. Initially I have been planning to use a SharedWorker for the prototype for the sake of getting it ready sooner. Nikhil, is there a bug for your work on Event Pages? If yes, I'd gladly follow that bug and will try to build something on top of your work there. Right now my patch doesn't do much over bent's rebased sharedworker patch. So you can start with it. I've to understand some of the code and think through some things, after which I can start a thread here about what Event page/Background services will behave. Nikhil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 2013-08-08 12:20 PM, Nikhil Marathe wrote: On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote: On Mon, Aug 5, 2013 at 3:17 PM, Nikhil Marathe wrote: On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote: On 26/07/13 18:29, Ehsan Akhgari 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! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir I'm experimenting with this. The SharedWorker patches are crucial to this, and I've spent some time trying to get them to work on m-c, before I can start working on this. Initially I have been planning to use a SharedWorker for the prototype for the sake of getting it ready sooner. Nikhil, is there a bug for your work on Event Pages? If yes, I'd gladly follow that bug and will try to build something on top of your work there. Right now my patch doesn't do much over bent's rebased sharedworker patch. So you can start with it. I've to understand some of the code and think through some things, after which I can start a thread here about what Event page/Background services will behave. I think you forgot the bug number. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
There is no bug number yet, because I have about 15 lines of additional code :) On Thu, Aug 8, 2013 at 3:52 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-08-08 12:20 PM, Nikhil Marathe wrote: On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote: On Mon, Aug 5, 2013 at 3:17 PM, Nikhil Marathe wrote: On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote: On 26/07/13 18:29, Ehsan Akhgari 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! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir I'm experimenting with this. The SharedWorker patches are crucial to this, and I've spent some time trying to get them to work on m-c, before I can start working on this. Initially I have been planning to use a SharedWorker for the prototype for the sake of getting it ready sooner. Nikhil, is there a bug for your work on Event Pages? If yes, I'd gladly follow that bug and will try to build something on top of your work there. Right now my patch doesn't do much over bent's rebased sharedworker patch. So you can start with it. I've to understand some of the code and think through some things, after which I can start a thread here about what Event page/Background services will behave. I think you forgot the bug number. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote: On 26/07/13 18:29, Ehsan Akhgari 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! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir I'm experimenting with this. The SharedWorker patches are crucial to this, and I've spent some time trying to get them to work on m-c, before I can start working on this. Nikhil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp ga...@gavinsharp.com wrote: Indeed. Somewhat off-topic for this thread, but I think this let's provide primitives and let other people build higher-level libraries trend for Web platform features is pretty dangerous. On the other hand, I think that the approach of spec and build 100 narrowly-focused features to solve 100 similar-but-different use-cases, as followed by (e.g.) CSS to date, is also dangerous. Guess what the right feature is, build it, and ship it, because you can't prototype solutions on top of the existing platform is dangerous too. It's certainly a balancing act :) I think we've been swinging a bit too far towards letting the perfect be the enemy of the good, is all. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 2013-07-30 4:14 PM, Gavin Sharp wrote: On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp ga...@gavinsharp.com wrote: Indeed. Somewhat off-topic for this thread, but I think this let's provide primitives and let other people build higher-level libraries trend for Web platform features is pretty dangerous. On the other hand, I think that the approach of spec and build 100 narrowly-focused features to solve 100 similar-but-different use-cases, as followed by (e.g.) CSS to date, is also dangerous. Guess what the right feature is, build it, and ship it, because you can't prototype solutions on top of the existing platform is dangerous too. It's certainly a balancing act :) I think we've been swinging a bit too far towards letting the perfect be the enemy of the good, is all. Do you have specific concerns about NavigationController? If yes, I'd like to know them! Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Intent to implement seems premature. Why wouldn't we wait to see how this goes and let Google do that. I really dislike the idea of rushing into this API. A programatic API that does something like AppCache is a good idea -- only in that it is better than the declarative shit AppCache is. We know (have data, getting more) that AppCache isn't used by the top 50k sites (it is probably only used in WebApps). IMO, We need more data to show that this API is more important than the n number of other things Mozilla wants to implement. I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. Didn't Jonas have a proposal for the 'offline' use case? Regards, Doug Ehsan Akhgari 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! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 2013-07-29 2:46 PM, Doug Turner wrote: Intent to implement seems premature. Why wouldn't we wait to see how this goes and let Google do that. I really dislike the idea of rushing into this API. What is the reason you think we should not implement this? We're not exactly rushing into *shipping* anything here. A programatic API that does something like AppCache is a good idea -- only in that it is better than the declarative shit AppCache is. We know (have data, getting more) that AppCache isn't used by the top 50k sites (it is probably only used in WebApps). IMO, We need more data to show that this API is more important than the n number of other things Mozilla wants to implement. The main reason why we're looking into this API is better offline support for web applications. I believe that this is the best proposal that anybody has in hand, and we need to prototype in order to make sure that this API is something that we want to support, and that it's not broken in similar ways to AppCache. I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. I'm still not sure what we're rushing into here. Didn't Jonas have a proposal for the 'offline' use case? Yes, he has proposed a declarative solution, which should be possible to implement on top of NavigationController. That is in fact one of our litmus tests for the viability of this API. Cheers, Ehsan Ehsan Akhgari 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! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner doug.tur...@gmail.com wrote: I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. Didn't Jonas have a proposal for the 'offline' use case? We did discuss at the last meeting. This API is the way toward making offline work and giving developers full control over that. Jonas' proposal offers a subset of the functionality. The current thinking is that offering developers the primitives will give us a better higher level API longer term. Offline not working seems like the #1 problem of the web platform, so working on this API does not really feel premature to me. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Do you think that NC is the right soluction here? Anne van Kesteren wrote: Offline not working seems like the #1 problem of the web platform, There are lots of problems with the web platform. Offline support is one of them, yes. :) so working on this API does not really feel premature to me. My issue wasn't if we were going to work on the 'off-line' problem or not. It was mostly around stating we're going to implement prematurely. It might be I don't really understand what the Intent to implement blink-like emails really mean.. if you say this, when is it going to show up in a FF release? Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Implementation detail, but I presume that you will also replace the existing appcache impl with NC, right? Ehsan Akhgari wrote: Offline not working seems like the #1 problem of the web platform, so working on this API does not really feel premature to me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
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
Re: Intent to implement: NavigationController
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
Re: Intent to implement: NavigationController
+1 that is awesome! I can see some interesting use cases for us in gaia where this would be helpful. On Fri, Jul 26, 2013 at 10:29 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: 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! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
