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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
