[webkit-dev] Fwd: Using WebKit's markup as facility of Chrome's DOM serializer
darin at apple.com
Thu Nov 20 09:32:32 PST 2008
On Nov 20, 2008, at 6:47 AM, Johnny Ding wrote:
> Now should I file a new bug on https://bugs.webkit.org/ for
> improving markup, then write the patch and send to you (plus someone
> else I should involve) for review? Is that a right process?
Yes, that's right. But you shouldn't target the patches at a specific
person for review unless it's a special circumstance. Put the patch up
for review by setting the "review+" flag on it.
It's important to do a small patch at first. If you do a lot of work
all in one patch it's going to be hard to find a reviewer for it.
If you do the changes incrementally, that's best.
Also, you should consider ways to expose these new markup engine
exposed on the web. That lets you make regression tests for each
feature that run as part of the regression test suite.
> For feature 1, the replacing logic will be implemented inside
> Markup. but user need to implement
> MarkupClient::getSavedLocalSubResourceURL to return correct local
> URL for input subresource URL If they want to replace all saved
> subresources with local URLs.
Yes, I understand that the mapping could involve a call to a function.
But also please consider if there's a way to build in a mechanism
where the markup machinery can invent URLs given a base URL that's
passed in. The fully flexible ability to put every subresource in any
URL the client chooses may not be all that helpful.
> For feature 5, In some of scenarios, one buffer is good enough for
> saving all serialized content. Other scenarios may want to do
> increment saving. I think It will be better to let users implement
> MarkupClient::saveMarkupContent to choose their prefer way. (using
> one buffer or using small buffer with increment process).
I agree that the API should be flexible, but I don't want to create
functions that are unnecessarily hard to use for basic things; that's
a mistake we've made in the past with WebKit that I want to do less of
in the future.
Lets talk about these specific items as you put patches together. I
suggest choosing some of the simpler items to do first to get a better
understanding of the patch review cycle and how to use regression
tests with these features, and to get a start on evolving the API of
the markup code.
More information about the webkit-dev