> (AT EYE-WATERING-LENGTH) I'm sorry I'm too verbose on the list for everyone's taste. Every time I'm brief and make assumptions, I get accusations like Jake's repeated ones that I'm just "asserting without reason".
FWIW, my exhaustion of this process is not about my eyes, but my fingers sure take a beating. :) > Ok, I think I understand what you're saying now. Happy we're on the same page there, then. :) > It's not scepticism at that level that I'm expressing. Accepting everything > you just typed out (AT EYE-WATERING-LENGTH), changes to Ian's proposal are > still a poor place to attack the issue. The Navigation Controller can give > you everything you want here and more. It's the right hammer for this > particular nail, not dependency attributes. I'm not arguing for dependency attributes, nor am I arguing that they should or should not do this or that. Jake and Ian are. I'm only trying to give them due consideration, through my prior posted code snippets (and others I'm working on) to examine what they do and do not afford as it relates to the use-cases I believe are important to consider. But I've stated that I actually don't like the dependency attribute, for many reasons previously stated, and further reasons I hope to demonstrate through the code comparisons Jake suggested. That is an ongoing effort to examine and explore the pros-and-cons, and is done in good faith. 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? 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. > 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. 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. I look forward to you helping remedy that. :) --Kyle
