2008/11/20 Darin Adler <[EMAIL PROTECTED]> > 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.
OK, How about my first step is creating a new class to hold all parameters current for mark-up code. After then I will incrementally implement above 5 feature one by one. Is it workable? Thanks. > > > -- Darin > > -- Best Regards. Johnny
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
