Intent to implement: NavigationController

[Ehsan Akhgari]

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/>

[James Lal]

+1 that is awesome! I can see some "interesting" use cases for us in gaia
where this would be helpful.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Aryeh Gregor]

On Fri, Jul 26, 2013 at 8:29 PM, Ehsan Akhgari <ehsan....@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.

[Ehsan Akhgari]

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/>

[Doug Turner]

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]

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

[Anne van Kesteren]

On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner <doug....@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/

[Doug Turner]

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

[Doug Turner]

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.

[Gijs Kruitbosch]

On 29/07/13 21:53 , Anne van Kesteren wrote:
> The current thinking is
> that offering developers the primitives will give us a better higher
> level API longer term.

Isn't that reasoning part of why we are now in the position where we
have indexeddb and nobody uses it, instead preferring localstorage which
is a worse implementation but a better (that is, easier) API? I'm not
convinced that's the right way to go about solving the offline usecase.

~ Gijs

[Anne van Kesteren]

On Mon, Jul 29, 2013 at 1:16 PM, Doug Turner <doug....@gmail.com> wrote:
> Do you think that NC is the right soluction here?

At a high level it seems like the kind of low-level API we want to
expose. The details are still muddy, we need implementation experience
and developer feedback for that.

> 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. :)

Agreed. Are there bigger problems, though? The impression I get from
developers is that offline is the main reason to develop native
applications over web applications. There are other reasons, too, but
not having offline solved is a dealbreaker.

>> 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?

The intent to implement helps us to know what ends up in our codebase
and lets us evaluate early on whether we think that's a good idea long
term. Intent to ship will be used to indicate when it shows up in a FF
(seems Fx lost :-)) release.


--
http://annevankesteren.nl/

[Nicholas Cameron]

On Tuesday, July 30, 2013 8:16:48 AM UTC+12, Doug Turner wrote:
> 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

Slightly off topic, but I really appreciate the 'intent to implement' email. It is good to know when people are working on something large and new. I would never otherwise have found out about this until it was released. I like to know when interesting things are happening which are a little bit outside my field of work, without having to trawl through the minutes for hundreds of meetings.

[Jonas Sicking]

We desperately need to get a better offline story.

The counter proposal to this that I had is going to take a lot longer
to hammer out and get to a state where we can ship. Or rather, it'll
take longer to get to a point where we're confident it's not repeating
a lot of the mistakes of appcache-v1.

So we should start with implementing NavController. I think the Apps
team is interested in working on doing a library implementation of my
proposal in parallel, but such a library will rely on having
NavController available.

That said, I suspect that the NavController API will need work. But
the best way to figure out what works and what doesn't is to implement
with that in mind.

/ Jonas

On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner <doug....@gmail.com> wrote:

[Gavin Sharp]

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. Having to "use a
library" to solve fundamental Web platform use cases (like "work
offline" or "store data") increases the barrier to entry for Web
developers pretty significantly. I understand that designing
high-level APIs can be hard and we won't always make the right
decisions, but I don't think we get to make that someone else's
problem if we really care about improving the Web platform in the near
term.

(There's a near-term vs. long-term distinction here too - "wait until
the libraries sort it out and then put that in the platform" approach
is costly if it means N additional months/years before the feature can
actually be relied on by Web developers. I understand the desire to
avoid backing ourselves into a bad compatibility corner and having to
maintain a "bad" API forever, but I think that's sometimes a tradeoff
worth making in order to drive progress.)

Gavin

[Robert O'Callahan]

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.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*

[Gavin Sharp]

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

[Ehsan Akhgari]

Do you have specific concerns about NavigationController? If yes, I'd
like to know them!

Thanks!
Ehsan

[Mounir Lamouri]

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

[nsm.n...@gmail.com]

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

[Ehsan Akhgari]

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.

[Nikhil Marathe]

On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote:

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

[Ehsan Akhgari]

I think you forgot the bug number. :-)

[Nikhil Marathe]

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....@gmail.com>wrote:

[Gervase Markham]

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

[Ehsan Akhgari]

On Thu, Aug 8, 2013 at 7:50 PM, Nikhil Marathe <nsm.n...@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/>