Yes, SPDY is a great idea, and of course I don't think that it -- or other ideas -- should be rejected just because of who proposes them or when. (As a concrete example, I am the lead editor of the W3C Touch Events spec and worked on implementing it in Gecko; it is an API that I absolutely believe should be standardized even though I strongly dislike how Apple originally designed and deployed it.)
I do think we agree on fundamentals though we may disagree on some cost-benefit analysis. All I meant about the "treadmill" is that some proposals have a much greater cost to implementers than others, and different organizations will weigh those costs differently. While some debaters may throw out "political or emotional" responses, I believe the decision-making process should be (and is, in the cases I've participated in) about allocation of resources, complexity of implementation, and the desired architecture of the web.
Technical issues and process issues are separate, but affect each other. When I say the process behind something like Touch Events was bad, I'm not giving that as a reason to reject the feature -- I think the feature should be accepted or rejected on its merits, like you said -- but it does mean that any technical objections that do appear will be much harder to resolve than they might have been. And as you say, Dart and NaCL have had better process behind them than Touch Events or various other extensions I could name. Dart and NaCL may succeed or they may fail (just as many of Mozilla's current experiments may suceed or fail), but at least their fates will be influenced by feedback from all stakeholders.
You are obviously better informed than I am about Dart and NaCL implementation. (Also, I accidentally conflated Go and Dart in my previous comment, which is embarrassing!) I apologize for any uninformed comments and defer to you on all the facts there.
I really don't want people to see this as a "Mozilla versus Google" thread. I hope everyone cares about standards issues because they help or hurt the web, not because they helps their favorite vendor or hurt a competing one. In the big picture, Google and Mozilla are close allies when it comes to web standards. As you say, the real risks to the open web are elsewhere.
I do think we agree on fundamentals though we may disagree on some cost-benefit analysis. All I meant about the "treadmill" is that some proposals have a much greater cost to implementers than others, and different organizations will weigh those costs differently. While some debaters may throw out "political or emotional" responses, I believe the decision-making process should be (and is, in the cases I've participated in) about allocation of resources, complexity of implementation, and the desired architecture of the web.
Technical issues and process issues are separate, but affect each other. When I say the process behind something like Touch Events was bad, I'm not giving that as a reason to reject the feature -- I think the feature should be accepted or rejected on its merits, like you said -- but it does mean that any technical objections that do appear will be much harder to resolve than they might have been. And as you say, Dart and NaCL have had better process behind them than Touch Events or various other extensions I could name. Dart and NaCL may succeed or they may fail (just as many of Mozilla's current experiments may suceed or fail), but at least their fates will be influenced by feedback from all stakeholders.
You are obviously better informed than I am about Dart and NaCL implementation. (Also, I accidentally conflated Go and Dart in my previous comment, which is embarrassing!) I apologize for any uninformed comments and defer to you on all the facts there.
I really don't want people to see this as a "Mozilla versus Google" thread. I hope everyone cares about standards issues because they help or hurt the web, not because they helps their favorite vendor or hurt a competing one. In the big picture, Google and Mozilla are close allies when it comes to web standards. As you say, the real risks to the open web are elsewhere.