Thanks a lot, Jarred. We're fine w/ hosting in other repo (but we'll be happier to live close to the WebKit). What would you suggest as a measure of success for this extra-repo branch?
yours, anton. On Tue, Dec 6, 2011 at 2:10 PM, Jarred Nicholls <jar...@webkit.org> wrote: > On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin <ant...@chromium.org> wrote: >> >> Good day, everyone! >> >> I am sorry if it didn't sound clear enough in our original message, >> but we're not proposing a new language support, but we're proposing a >> patch which allows others runtimes to run along with JS in the >> browser. >> >> Of course, we're doing this because of our work on Dart, but our >> intent was to solicit a feedback from the WebKit community if there is >> any interest in supporting runtimes additional to JS (and not JS + >> Dart) in the first place. >> >> And we're not only talking about the browsers proper, our hope was, >> for example, that people embedding WebKit into apps may benefit from >> hopefully tight integration or, another idea, if we can provide better >> isolation for JS proper using similar approach. >> >> And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897 >> ---is only a tiny step in this direction---Fillip is absolutely right >> that integrating several GCing VMs is tricky---we're pretty much aware >> of this and hope we can address this, but, again, the patch is only >> initial infrastructure to enable more than a single runtime. >> >> If consensus in the community is nobody needs more than JS runtime in >> the browser (for any reason), so it be---we looked for feedback from >> the community and we got it. If the community response is idea is >> good, but you need to account for..., great, we're happy to do that. >> Maybe it'll make this patch feel less experimental and Geoff would be >> less reluctant to see it on the branch. > > > It would be easier to just host the branch in a mirror somewhere else, > continue experiments there, and report back to the community. Many others > do this, e.g., Samsung and WebCL. > >> >> >> And I can definitely understand concerns which are raised by Dart in >> the browser, but I really hope it's a separate issue. >> >> Thank you very much all for your feedback! >> >> yours, >> anton. >> >> On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt <oli...@apple.com> wrote: >> > No. People are using EcmaScript on the web. >> > >> > They have languages that compile to EcmaScript as an intermediate >> > language. Dart could also do this (emscripten demonstrates that raw C can >> > be compiled to EcmaScript), so if people wished they could do that. These >> > are also not a significant proportion of websites at all. If we were to >> > decide to support one of these natively it would make sense to support the >> > most popular and widely used languages, but currently none of the languages >> > that compile to ES have made any significant headway -- mostly because ES >> > is >> > actually a pretty good language (yes it has rough edges, but the same is >> > true of _all_ languages). >> > >> > Adding direct and exposed support for a non-standard language is hostile >> > to the open-web by skipping any form "consensus" driven language >> > development >> > that might happen (say the path taken by json2.js -> the native JSON >> > object), and foisting whatever language we want on the web instead. >> > This implicitly puts any browser that supports additional proprietary >> > extensions in the same position as a browser supporting something like >> > vbscript, and has the same effect: breaking the open web by making content >> > that only works effectively in a single product. >> > >> > For example back in the 90s Netscape had a feature called "layers" any >> > browser could display the pages, but they would only look "good" in >> > netscape. If we were to natively support some other language on the web >> > say >> > OliversAwesomeWebLanguage, and provided a tool to compile OAWL to ES any >> > site that used OAWL would perform significantly worse on other browsers >> > than >> > on our own (this is a given as the only argument in favour of native >> > support >> > vs. compilation to JS is that native support is meant faster than going >> > through JS). >> > >> > If OAWL did become a big enough platform then other vendors _might_ end >> > up reversing engineering it and reimplementing it themselves, put us back >> > in >> > the position of the 90s browsers and the many variants of what is now >> > called >> > EcmaScript. >> > >> > On Dec 5, 2011, at 10:43 PM, Vijay Menon wrote: >> > >> >> On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt <oli...@apple.com> wrote: >> >>> >> >>> The issue here isn't "can we make multiple vms live in webkit" it's >> >>> "can we >> >>> expose multiple languages to the web", to the former i say obviously >> >>> as we >> >>> already do, to the latter I say that we don't want to. >> >> >> >> People are already using multiple languages on the web. E.g., >> >> >> >> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS. >> >> Native runtime support is a natural next step. >> >> >> >> WebKit does support multiple VMs, but it does not support them >> >> concurrently at runtime. That is essentially what we want to enable. >> > >> > WebKit does support multiple bindings concurrently at runtime -- a lot >> > of mac clients make use of the obj-c dom bindings while JS is executing, >> > some also make use of the JS<->ObjC bridge so that you have two different >> > sets of bindings for the same objects at the same time, being used together >> > in beautiful harmony ;) >> > >> >> >> >> Cheers, >> >> >> >> Vijay >> > >> > --Oliver >> > _______________________________________________ >> > webkit-dev mailing list >> > webkit-dev@lists.webkit.org >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev