- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 12 Jul 2013 21:00:40 +0100
- To: Kyle Simpson <getify@gmail.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Fri, Jul 12, 2013 at 7:56 PM, Kyle Simpson <getify@gmail.com> wrote: [ snip ] > Again: my question (which remains unanswered), & the reason I stated the > error/retry/fallback use case in detail, is whether or not the dependency > attributes proposal, as put forth by Jake (and Ian) will or will not, > factually speaking, have any sensitivity to the error conditions (network > load error, compile error, run-time error) or not, or somewhere in between? > As per the existing outline, I don't see how it could have any "sensitivity". > If `dependencies` IS sensitive, in any way, then it clearly overlaps > Navigation Controller, right? That may or may not be a good thing. If OTOH > it has no sensitivity whatsoever, and it will trigger a subsequent waiting > resource regardless of ANY particular network condition or result, that is > vital information to know, as well. > > Either way, shouldn't we afford enough discussion here to discuss how > little or how much, or if at all, that sensitivity would be? I certainly > can't adequately judge the proposal in the absence of that information. > > Isn't it fair enough for me to inquire as to the actual nature of their > proposal, given that they've asserted in no uncertain terms that it is > fully sufficient for all my use-cases? Aren't I entitled to examine that > with the assistance and participation of this list? > > None of that means I necessarily think that Navigation Controller is or is > not ALSO suitable. I have no opinion on that yet. I stated the reasons why > I have no opinion on it yet. > > Presenting an alternate proposal for one or more use-cases, as you have > done, is fine. But that doesn't mean that it answers the questions I have > about the other proposal, by Jake and Ian. Those pre-existing questions are > my concern, presently. > > > > > We're working on implementing it in Chrome. So yes, both likely and soon. > > I look forward to seeing more great documentation on it as we've all come > to appreciate from the Chrome and Developer relations teams. I owe this list (and others) mail about it. Hoping to have that ready soon. > > It's unfair of you to expand the scope of a proposed feature to include > your pet issue when, logically, it can be separated. See what we both just > did there? > > Expand the scope? I am not expanding the scope beyond that which I've > pushed for over and over again for 3+ years, this thread just being the > latest incarnation. That others (like you) may come to this list with a > pre-conceived notion of what is and is not "in scope" doesn't mean that me > stating (in response to repeated appeals from Jake and others) at length > the use-cases *I* care about is actually "expanding" that scope. > I think you missed the second sentence... > Moreover, I am the originator, or at least one of them, of the "proposed > feature", so I hardly think it's fair for you assert that I'm changing the > game. In reality, I'm clarifying the "proposed feature" as it relates to my > viewpoint, as an interested party acting in good faith. I'm recounting the > substantial "prior art" in the discussions and discovery and > experimentation. > > No, I'm not expanding the scope. You (and others) appear to want to be > narrowing the scope that well pre-dates this thread. > > My scope (as it always has been) put simply: I want (for all the reasons > here and before) to have a "silver bullet" in script loading, which lets me > load any number of scripts in parallel, and to the extent that is > reasonable, be fully in control of what order they run in, if at all, > responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might > have existed at the time of initial request. I want such a facility because > I want to continue to have LABjs be a best-in-class fully-capable script > loader that sets the standard for best-practice on-demand script loading. > > > > > Better to ask how best to accomplish our goals, not fight over where to > do that. And that's the spirit I offered the NC in (and pour my work into > it over). Happy to discuss NC over at the github repo, FWIW. > > Fair enough. That spirit is certainly appreciated. > > At the request of this list, I presented the use-cases as they stand, and > as they always have. Any solution(s) which reasonably meet them would be a > good candidate. We're seeking solutions, but we're doing so by exploring > the fitness of various proposals. > > Over the years, I've championed no fewer than 3 different proposals for > how I see a single coherent solution that solves all the use cases. That > alone ought to demonstrate sufficient good-faith that I'm looking for > solutions, not impetuously defending my "pet". > > Moreover, especially with this most recent proposal (<script preload>), I > believe it not only sufficient to (trivially) handle *all* the use-cases > I've presented, but also it is of the nature that it basically would answer > nearly any other use-case you could imagine in script loading. Certainly my > list is long but not fully exhaustive of every niche need/desire. > > In light of my proposal(s), none of which have been substantially refuted > as inferior, I of course am advocating for whatever solution we end on to > actually handle all the things my proposal would handle. Any proposal which > substantially does not is, in my opinion, insufficient. > > You may want to contract the scope to leave some of my use-cases out of > luck, but I'm entitled to avidly defend why I think that's unfair and the > wrong approach. > > I am not married to my current proposal. If there is a single coherent > solution, or some reasonable combination of them, which clearly will handle > all the use-cases, and we can examine and compare WITH CODE (not just > hypothetical ideas), as Jake suggests, great. > > But thus far, Navigation Controller is far behind the proposals of > `<script preload>` and `<link rel=subresource> + <script dependencies=..>` > in terms of being able to compare use-case coverage with actual practical > code. > That's only your ignorance speaking. There are examples in the repo which you can use to extrapolate examples, or if you a code snippet showing the problem, either Jake or I can show how NC would address it. > I look forward to you helping remedy that. :) > > > > > --Kyle > > > > >
Received on Friday, 12 July 2013 20:01:36 UTC