[webkit-dev] webkit editing rewrite?

[Alex Russell]

On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen <ggaren at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>