<br><br><div class="gmail_quote">2008/11/20 Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com">darin@apple.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Nov 20, 2008, at 6:47 AM, Johnny Ding wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Now should I file a new bug on <a href="https://bugs.webkit.org/" target="_blank">https://bugs.webkit.org/</a> for improving markup, then write the patch and send to you (plus someone else I should involve) for review? Is that a right process?<br>

</blockquote>
<br></div>
Yes, that&#39;s right. But you shouldn&#39;t target the patches at a specific person for review unless it&#39;s a special circumstance. Put the patch up for review by setting the &quot;review+&quot; flag on it.<br>
<br>
It&#39;s important to do a small patch at first. If you do a lot of work all in one patch it&#39;s going to be hard to find a reviewer for it.<br>
<br>
If you do the changes incrementally, that&#39;s best.<br>
<br>
Also, you should consider ways to expose these new markup engine features to JavaScript in DumpRenderTree, even if they wouldn&#39;t be exposed on the web. That lets you make regression tests for each feature that run as part of the regression test suite.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For feature 1, the replacing logic will be implemented inside Markup. but &nbsp;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.<br>

</blockquote>
<br>
<br></div>
Yes, I understand that the mapping could involve a call to a function. But also please consider if there&#39;s a way to build in a mechanism where the markup machinery can invent URLs given a base URL that&#39;s passed in. The fully flexible ability to put every subresource in any URL the client chooses may not be all that helpful.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For feature 5, &nbsp;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).<br>

</blockquote>
<br></div>
I agree that the API should be flexible, but I don&#39;t want to create functions that are unnecessarily hard to use for basic things; that&#39;s a mistake we&#39;ve made in the past with WebKit that I want to do less of in the future.<br>

<br>
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.</blockquote>
<div>OK, How about my first step is creating a new class to hold all parameters current&nbsp; for mark-up code. After then I will incrementally implement above 5 feature one by one. Is it workable? Thanks.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><font color="#888888">
<br>
 &nbsp; &nbsp;-- Darin<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Best Regards.<br>Johnny<br>