Sure, although I've only just started (have only updated the code to reflect
the changes to WorkerObjectProxy/WorkerContextProxy on the WebCore side, and
am now cascading the changes down into the WebKit API/browser).
http://codereview.chromium.org/173193
Thanks for the help, everyone. I think I see how to move forward now.
-atw
On Thu, Aug 20, 2009 at 11:22 PM, Darin Fisher <da...@chromium.org> wrote:
> It would be easier to recommend advice if I could see / review the code.
> Can you provide a link to the in-progress CL?
> -Darin
>
>
>
> On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson <atwil...@chromium.org>wrote:
>
>>
>>
>> On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher <da...@chromium.org> wrote:
>>
>>> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher <da...@chromium.org>wrote:
>>>
>>>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson <atwil...@chromium.org>wrote:
>>>>
>>>>> I have to admit I'm somewhat fuzzy on the motivation behind our webkit
>>>>> API, although I gather the plan is to eventually upstream it to WebKit,
>>>>> and
>>>>> use it as our abstraction layer instead of using the (more mutable)
>>>>> WebCore
>>>>> APIs? Or is there another motivation?
>>>>> I'm just curious because it seems like every non-backwards-compatible
>>>>> change I have to make to WebCore seems to translate to a similar change to
>>>>> the WebKit API (case in point, I'm currently changing parameters to
>>>>> MessagePort.postMessage() to take multiple ports instead of a single port
>>>>> and this requires changes to things like WebKit::WebChannel), so
>>>>> upstreaming
>>>>> the WebKit API wouldn't really shield us from breakage in those cases.
>>>>>
>>>>> Anyhow, I'm trying to understand the philosophy around when to use
>>>>> classes like WebVector (our WebKit API version of Vector).
>>>>>
>>>>
>>>> I try to avoid WebVector since it necessitates a copy. I'm not sure
>>>> that I really want to keep it in the API long term. It is a crutch to help
>>>> us out. On the Chromium side, use std::vector. On the WebKit side, use
>>>> WTF::Vector. WebVector should only be used for data exchange, and should
>>>> just be a temporary.
>>>>
>>>
>> Here's the crux of the issue.
>>
>> WebMessagePortChannel.h is defined in src/webkit/api/public. I'm assuming
>> we can't use std::vector here since we ultimately want to upstream this. It
>> seems like our only choices here are to use WTF::Vector or WebVector.
>>
>> The implementation of WebMessagePortChannel is in
>> src/chrome/common/webmessageportchannel_impl.cc. We can't use WTF::Vector
>> here (I'm assuming) since that belies the whole point of the webkit API.
>>
>> So it seems like I do need to use WebVector here. Luckily, I don't then
>> need to pass this data around anywhere else (it's converted to a vector of
>> ints and passed through IPC) so I can avoid doing any copies.
>>
>>
>>>
>>>> In some cases, visitor or iterator patterns can be better than a
>>>> WebVector. See WebHTTPHeaderVisitor and WebPluginListBuilder for examples.
>>>>
>>>
>> I really need to pass ownership of an array of data around, so I don't
>> think those patterns will work here.
>>
>> Speaking of which, how do we capture the idea of passing ownership of a
>> pointer? If this were in WebCore, I'd use WTF::OwnPtr/PassOwnPtr to signify
>> that I was passing off ownership of a pointer. Is there an analogous idiom
>> in the Chrome codebase and/or the Chrome WebKit API?
>>
>>
>>>
>>>> -Darin
>>>>
>>>>
>>> doh, one more thing... i'm toying with the idea of just making WebVector
>>> be implemented as a std::vector in our configuration, allowing still for
>>> other configurations where it might be implemented using a different native
>>> type. if i did that, then i'd be happier with WebVector because at least it
>>> would only require one copy... between std::vector and WTF::Vector.
>>>
>>> -darin
>>>
>>>
>>>
>>>>
>>>>
>>>>> I'm updating some of the WebKit API classes to accept a WebVector as a
>>>>> parameter as part of the change described above. Down in the calling code,
>>>>> should I use STL classes like std::vector, and then convert to WebVector
>>>>> only when actually calling into the WebKit API? Or should I use WebVector
>>>>> elsewhere in the code (like down in the glue code)? It's certainly more
>>>>> efficient *not* to have to convert between std::vector and WebVector if I
>>>>> don't have to, but that seems like a slippery slope as WebKit API classes
>>>>> would start spreading through the rest of the codebase.
>>>>>
>>>>> Any guidance for me?
>>>>>
>>>>> -atw
>>>>>
>>>>> >>>>>
>>>>>
>>>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
