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

[Johnny Ding]

2008/11/20 Darin Adler <darin at apple.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081121/4206476a/attachment.html>