[webkit-dev] Fwd: Using WebKit's markup as facility of Chrome's DOM serializer

[Darin Adler]

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  
features to JavaScript in DumpRenderTree, even if they wouldn't be  
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.

     -- Darin