[webkit-dev] webkit editing rewrite?
slightlyoff at google.com
Wed Aug 4 08:36:53 PDT 2010
On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> -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)
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
> 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
>> -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.
>> -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.
> 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.
> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev