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 -~----------~----~----~----~------~----~------~--~---