Brendan, Thank you for the thorough and even somewhat inspiring response, that certainly helps me (and hopefully others) to understand the situation better. I may a have few other questions later, but for now, Thank you! Kris
On 10/30/07, Brendan Eich <[EMAIL PROTECTED]> wrote: > > [Kris asks legitimate questions, to be answered by more than a Microsoft > spokesperson. I'm going to reply cc'ing the list, even though there are > political points here along with technical content. The list is for > discussion of ES4, and that category looks like it must include some > political discussion. > > > Also, this reply is LONG. Sorry, I've tried to compress without doing > anyone an injustice. > > > Skip if you want to avoid any political content. If you think I'm FUDding > or attacking individuals unfairly, call me on it -- with specific quotations > if possible. If I'm out of line, I'll apologize to the list and amend my > words. If we simply disagree on the fundamental substance, that's good to > know too. > > > I'm trying to shed some light on what has clearly been too much of a > dark-room standards process, excluding the materials we've exported at > http://ecmascript.org/. > > > /be] > > > On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote: > > From a pragmatic perspective, it seems to that the critical goal behind > all of this, is what will bring a better development environment for the > future of the web, and the key to this is what will be broadly implemented. > The choice of the name is of course around this central issue since the ES > title brings such a strong motivitation for implementation. However, if ~10 > years > > > > > Try two years -- ten is way, way too long for developers to wait, and > anyway beyond any credible crystal ball's range. The proprietary stacks from > Microsoft and Adobe won't wait that long for competition from browser-based > web standards, as Doug Crockford and others warn; they'll propagate all over > the web well before ten years. > > down the road, ES4 is not implemented broadly enough that web developers > can code to it, than it is of signficantly less value. While unanimity is > not needed for a standard to be passed, if the one of the key browser > vendors will not implement it, than how valuable are our efforts? > > > > > Let's find out, by having a standard that browsers and plugins can choose > to implement for interoperability and shared developer knowledge. Enough > companies want ES4 as a standard that (absent technical problems), it ought > to become one, whether or not all browser vendors buy into it. > > > If you give all the power over standardization to any one company, then > you are that company's slave, and I predict you'll get treated accordingly. > This happened once already, after IE achieved a virtual monopoly. Just > consider all the unfixed JScript bugs, many dating to IE4, still in IE7. > > > > I know that there are, or will be efforts to provide a Tamarin plugin for > other browsers, but is this really what we are pinning our hope on? > > > > > Not necessarily, but (hey, I came up with it > <http://weblogs.mozillazine.org/roadmap/archives/2007/07/new_projects.html>;-) > it's not a bad plan absent competitive pressure on Microsoft to support ES4 > in IE. > > > You may not know this, but minority-share browsers do not have as low > market share as the Comscore and WebSideStory analytics firms' results show > in aggregate for the U.S.. At high value sites, visited more frequently by > "lead users" and otherwise influential (and better-monetized) visitors, > Firefox, Safari, and Opera do better -- sometimes much better. If you look > at Xiti's > results<http://www.xitimonitor.com/en-us/browsers-barometer/firefox-july-2007/index-1-2-3-102.html>for > Europe, Firefox is trending to cross the 50% market-share line in some > countries. > > > Whatever you do, never give up your own sovereignty as a browser user or a > web developer to a dominant player. You always have a choice. > > Plugins usually don't reach necessary distribution for developers to rely > on them. > > > > > Counterexample: the Flash Player. > > > I have no idea whether Flash would ship ScreamingMonkey support. I > certainly hope so, given Microsoft's rejection since early this year of ES4. > > Or are we hoping that the ES4 title will be sufficient to get an > implementation from every vendor? > > > > > Title, schmitle. :-) The "brand value" of ES4 may be an issue for browser > vendors, but it is not the main issue for developers, and users don't know > or care. What matters is whether web developers can effectively demand, and > count, on near ubiquity and quality from ES4 implementations, soon (a year > or two). That is an open question, as noted above -- and there are several > reasons to have hope. > > I certainly acknowledge that it is insidious that there might a > suggestion to design around one member, but I will still ask, is there any > concessions that can be made to increase the probability that MS would > implement ES4 in the future? > > > > > No. Without speaking for anyone else, I am now going to give more > information about what has already been said inside TG1, since the TG1 > dispute has already spilled out into the blogosphere since last week's Ajax > Experience East, when as part of a panel discussion, Doug Crockford made > some statements about TG1 members and motives. Others in TG1 can back this > up, and anyone can check our meeting minutes, which are public at > http://wiki.ecmascript.org/ with complete revision histories. > > > While at certain times, as in late 2006 and before March > 2007<http://wiki.ecmascript.org/doku.php?id=discussion:browser_profile>, > Microsoft talked in TG1 (or possibly just to me) about perhaps > standardizing > JS1.7<http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7>in Firefox > 2, at other times we have heard a very clear "No" to the question > of substantive changes from ES3 like those in Firefox: No JS1.7extensions, no > change from ES3 apart from deprecations and maintenance. > > > IIRC, you yourself heard a "No" in reply to your "JS1.7 features coming in > IE?" face-to-face question posed to Chris Wilson at The Ajax Experience West > this summer (I happened to be nearby at the time). I recall seeing some > back-peddling to avoid committing either way in a comment from Chris at > http://ajaxian.com after that, but you tell me: do you really expect > anything more, given statements such as Allen Wirfs-Brock's comment at Ric > Johnson's OpenAjax > blog<http://openajax.com/blog/2007/10/29/god-bless-scoble/>, > and the content available at the JScript > blog<http://blogs.msdn.com/jscript/archive/2007/10/29/ecmascript-3-and-beyond.aspx> > ? > > > Sure, a Microsoft "vision" for JScript will be rolled out, real soon now. > Based on everything we've heard in TG1, it is safe to say that the vision is > either a fork of ES3 away from ES4, or a lot of do-nothing posturing about > maintenance and safeguarding compatibility, to give Silverlight and WPF time > to penetrate the Web. I would love to be proven wrong -- c'mon, Microsoft, > make me eat my words (happily): embrace (and extend, for all I care) ES4. > Just get the mandatory core language right, as in, far fewer overt bugs than > JScript vs. ES3. > > Perhaps this has already been discussed, so I apologize if it has. Does > MS have specific issues, or is their dissent simply for the purpose of > avoiding committing to implementation (regardless of the content of ES4)? Is > security one of the main issues? Is it the size and scope of the language? > From what I understand, I think these are Crockford's concerns, although I > don't know if that is true for MS. > > > > > One at a time: > > > * Not only the majority of TG1, but many on this list, have asked for > specific technical objections, and received none in reply. Even a summary > technical judgment against ES4 in full needs to be decomposable into smaller > technical arguments. ES4 needs to be fully specified and implemented, for > sure, so we're not claiming it is done or proven yet. But disproof that > disqualifies it as a candidate successor edition needs to be demonstrated. > > > On a positive note, I will say this: as a working group, when we have not > been wearing political armor, we've had productive technical dialogs about > proposed ES4 features and their progenitors in the literature, especially > with Allen Wirfs-Brock. But the Microsoft position (so-called -- it's clear > when Allen is speaking for Microsoft, which is a good thing!) has not > consisted of detailed analysis and conclusions against specific technical > features. It has simply been a summary judgment expressed as "Microsoft > opposes ES4" and (memorably, from April) "the web doesn't need to change > much". > > > * The browser > profile<http://wiki.ecmascript.org/doku.php?id=discussion:browser_profile> I > cited above, started by Pratap Lakshman of Microsoft, was superseded by an > ES3.1<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft> > proposal, > which was made following an agreement at the March TG1 meeting. At that > meeting, it was also agreed that any ES3.1 would be implemented as a > subset of the ES4 reference implementation (for testability) This has not > happened. > > > Everyone also agreed at the March meeting that ES3.1 would not be approved > by TG1 until it could be evaluated for forward and backward compatibility. > Finally, I recorded an agreement at least among the majority of TG1 that > ES3.1 was not approved of as a standard-to-be, but was something the > majority thought could be explored further by the minority group, under > TG1's charter from TC39. > > > Note that the "3.1" name does not work in Ecma terms. There is no minor > edition process in Ecma (mozilla.org has hosted the only > errata<http://www.mozilla.org/js/language/E262-3-errata.html>page), so if > ES3.1 were standardized as a successor to ES3, it would be renamed the 4th > Edition. This obviously would create conflict in TG1 and confusion in the > market. > > > * ES3.1 was superseded by no substantive work in the es3.1 section of the > wiki since April<http://wiki.ecmascript.org/doku.php?do=recent&first=100&id=>. > Instead, two documents describing JScript (one about the @if/@else/@endif > preprocessor<http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%253Aresources&cache=cache&media=resources:jscriptconditionalcompilation2.doc> > > (PDF<http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%253Aresources&cache=cache&media=resources:jscriptconditionalcompilation3.pdf>), > the other about JScript > deviations<http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%253Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf>from > ES3), have been produced by Pratap. These are informative, but not even > potentially normative as written, except where browser implementations have > already matched JScript (in order to gain market share by interoperating) -- > and ES4 already contains such bug fixes to ES3. > > > * Security is an "issue" (not in the Oprah sense), all right. A bit more > precisely, it is a set of end-to-end properties that need solid enforcement > mechanisms at many layers of abstraction. Security is however *not* a > unitary good or "product". You sometimes hear demands for TG1, or all > browser vendors, to stop the world and work on security. That is an > unrealistic demand; the world doesn't work that way. > > > We've talked a bit in TG1 about security properties, mainly Integrity and > Confidentiality. Apart from making ES4 statically checkable and improving > binding forms to reduce mutation hazards, we are not biting off riskier > work. The academic research is not solid yet (unlike the research on > multimethods, for example). There is no good way that anyone involved in TG1 > can see, in the core ECMAScript language only, to standardize a capability > system for the web. > > > It's clear from experience from Mozilla and many security researchers that > even *a posteriori *mashups built on a capability system will leak > information. So information flow type systems could be explored, but again > the research on hybrid techniques that do not require *a > priori*maximum-authority judgments, which do not work on the web (think > mashups in > the browser without the user having to click "OK" to get rid of a dialog), > simply is not there yet. Mashups are unplanned, emergent. Users click "OK" > when they shouldn't. These are hard, multi-disciplinary research problems. > > > Experiments such as Google > Caja<http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf>are > interesting ( > discussion<http://www.nabble.com/Initial-draft-Caja-design-docs---library-now-available-t4611010.html>here), > and Mark Miller will (I hope) smite me mightily if I misspeak about > it, but as far as I can tell, such systems create an incompatible subset of > JS into which developers may "opt" -- not a successor standard for the > ECMAScript language that is backward compatible. Such a subset could be a > very good thing, don't get me wrong. But it does not fall neatly under TG1's > charter, because it's not backward-compatible, and profiled standards are > considered harmful. > > > Anyway, it's early days for Caja and other such systems. If TG1 continues > to function, it should definitely harvest good ideas from it, and stand on > shoulders, not toes. > > > We've pressed Doug Crockford on this point and heard nothing in the way of > concrete proposals, save for a small one I championed at the last > face-to-face meeting (a better-isolated String.prototype.evaluate() taking > a scope object). But that went nowhere for lack of effort -- I half expect > it to turn up in "Microsoft's vision for ECMAScript", which would make a > fork in the standard. I'll still try to rescue it for ES4, but it's just a > small isolation device, good to have, but not nearly enough for "Security" > with a capital S. > > > I hope to hear more from Doug and others as things evolve, but ideas like > a capability-based message-passing architecture built on Google Gears, which > Doug proposed at a > talk<http://video.google.com/videoplay?docid=452089494323007214>given at > Google recently, do not fit in ES4's schedule and mandate to avoid > premature standardization. ES4 is not about to normatively specify Google > Gears APIs, which only came out this past spring. Gears APIs for > workerpools <http://code.google.com/apis/gears/api_workerpool.html> are a > great idea, but they are out of scope for the core language, which has not > only an apparently single-thread execution model, but one-thread-only and > even zero-OS implementations. > > > APIs such as those purveyed by Gears should be standardized in the WHAT-WG > and/or the W3C (and I've seen some WHAT-WG standardization work on Gears > already). > > I think that if even 25% subset of ES4 was uniformly implemented in all > browsers in 10 years, web developers would be vastly further along than if > the 100% of ES4 was implemented in half the browsers. > > > > > You're kidding, right? Ten years is far too long, and there's no coherent > 25% -- a lot of ES4 depends on the type system. Would you cut that and try > to stitch the remaining pieces back together? King Solomon only offered to > bisect a child to find the true mother. Quartering was not a good idea even > for that purpose. Anyway, Microsoft is now the avowed anti-mother of ES4, so > you are only going to help mutilate or kill ES4 with this kind of > bargaining. > > > To switch metaphors to something less biblical, gory, and humorless: given > the on-again/off-again flirtation with JS1.7 compatibility by Microsoft in > TG1, I would not be surprised if you got a little foot-bumping under the > table. But take it from me, they are teasing. ;-) > > While unfortunate that such orthogonal issues could affect language > design, and perhaps stifle innovation, I would like to see what will be best > for the future of the web. > Does anybody know if there is anything that can be done to increase the > likelood of full cross browser implementation of ES4? Does anyone know the > issues or parts of ES4 that are causing dissent? Is it the impact of the > size of the language (on security, implementability, etc)? > Apologies for my excessive pragmatism, > > > > I don't think you are being pragmatic. I think you are making yourself too > much of a victim :-], seemingly giving all power to the dominant player and > hoping for some scraps from the table. Pragmatism means using the tools you > have and looking out for your own interests, even if it is scary, or > requires some risk in the short run. > > > For me, pragmatism means ES4 as a standard that any browser can > interoperably implement and deploy, with ScreamingMonkey for browsers that > don't like ES4. > > > The world can change. Before Firefox, there was no hope. Who knew in 2002 > or 2003 that we would be having an exchange like this one, within (my best > prediction) a year or two of ES4 support rolling out, possibly to the > majority of browsers? To quote from a great movie: Never give up, never > surrender! ;-) > > > /be >
_______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
