On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen <gga...@apple.com> wrote: >> Some of us had a somewhat crazy idea to rewrite much of the editing code >> (e.g. document.execCommand) in JavaScript. >> >> Pros: > >> -Ensures that the APIs we expose to the web are at least good enough for our >> own editing code > > I don't think this necessarily follows. Not everything exposed to the > internal editing implementation would necessarily be exposed to the web. If > we required that everything exposed to the internal editing implementation be > exposed to the web, that would substantially slow development, since every > new API would need to be vetted and possibly standardized. So this is either > not true or a substantial con.
It's not like that's a serial process. More to the point, assuming the current command API is the result (as proposed) and that DOM ranges are supported, it's unclear that standardization is a major risk. In any case, we won't get better APIs if we don't try and the current APIs suck hard. >> -Ensures that editing code never crashes (outside of JSC/V8 bugs) > > JavaScript can still crash -- you just get an unhandled exception instead of > a segfault. It's not clear to me why that would be better. I can think of > reasons why it would be worse: These crashes are much less likely to be exploitable security issues. That's one (major) plus. > - Can't use standard OS tools like CrashReporter to detect problem areas. > - Harder to debug, since you need to use the Web Inspector, which: > - doesn't have all the features of modern C++ debuggers, like > watchpoints and breakpoint commands > - creates a circular dependency > - Sometimes, instead of an unhandled exception, you'll just get incorrect > behavior that's very hard to track down. > > A similar set of cons pertains to performance issues. I'm not sure that's clearly true. >> -Gives a clean slate for starting the editing code anew > > This is an argument for a rewrite, not an argument for JavaScript. A rewrite > can happen in any language. > > A rewrite is not self-evidently a good thing. Nobody suggested it was? The basis for the suggestion is: * today's JS APIs are not fit for the tasks that are being asked of them * the command system isn't extensible from JS, causing incredible amounts of hackery and rework in every JS wrapper for editors * when things go south in the current system, crashes are potentially exploitable >> -Moves code out of WebCore > > Changing the language doesn't move the code out of WebCore. > > Moving code out of WebCore is not self-evidently a good thing. > >> -If other browser vendors choose to expose the same APIs, then we can share >> the editing library and make the world better for web developers > > That's a big if. Do you have any evidence that other vendors are interested? > Are there vendors specifically interested in adopting WebKit's editing > library, but not WebKit as a whole? That would surprise me. Fair enough, but consider the case of a rich text editing system as exists in products like GMail and Mobile Me where the current infrastructure is as much a liability as an asset. For those systems, having better plumbing and being able to operate on more deterministic, low-level APIs for editing would be a serious plus. >> Cons: >> -Potentially slower since DOM calls are now JS-->C++ >> -Potential for regressions due to holes in the layout test coverage >> -Not statically typed > > I notice that you don't mention the added complexity of gluing two languages > together for core DOM operations. I think that's probably the main con. The bindings are already opaque. How is this really worse? >> I'm not too concerned about the perf hit. It should be no more than a >> constant-factor and, historically, the editing perf problems have been >> order-of-magnitude issues. > > You're not considering the hurt that the editing JavaScript code could put on > website code. If the editing memory footprint is large, the GC hit on other > websites could be substantial. > > JavaScript's scoping rules also have a nasty tendency to introduce accidental > memory references that keep large object graphs alive, exacerbating this > problem. Luckily Ojan et. al. happen to be very good at JavaScript ;-) Regards > For security reasons, we might need to instantiate a new copy of the editing > code for every webpage. That could be a substantial memory use regression. > >> As for the functionality regressions, I think they're inevitable. We'd hit >> most of the same issues trying to refactor the existing C++ code on top of >> better APIs. > > I agree that a rewrite inevitably introduces a large number of bugs, > regardless of whether it happens in C++ or JavaScript. > > However, I don't agree that refactoring inevitably introduces just as many > bugs as rewriting. I would submit that the entire history of the WebKit > project demonstrates the value of refactoring over rewriting. > > Geoff > _______________________________________________ > 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
