[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 9:17 PM, Drew Wilson 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? Roughly speaking, the intention as I understand it is for it to be a stable, well defined C++ API that serves the same purpose as Apple's Objective-C API. With such an API, applications (such as Chromium) or other frameworks (such as CEF) would not have to be tweaked continuously to keep in sync with WebKit (much as Mac applications that use WebViews don't have to be tweaked very often to stay compatible with WebKit nightlies). Speaking from prior experience, stable interface layers can be a bit of a pain to create and maintain, but much less than the pain of trying to stay in sync with a continuously changing target. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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? That's one major benefit. Another one is that WebKit could be built as a DLL with only a small surface area of entry-points. Another one is that it forces us to clean up some really messy code and dependencies. But probably the biggest benefit is that it "documents" how we're using WebCore. Once we have a build bot on http://build.webkit.org that builds with our API, other WebKit developers will be able to see when they break us. Eventually we'll also be running layout tests against our version of WebKit+WebCore+V8+SKIA which will do even more "documenting". > 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. > Agreed, but it help with the case of others breaking us. > Anyhow, I'm trying to understand the philosophy around when to use classes > like WebVector (our WebKit API version of Vector). 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. > Agreed about the slippery slope part. I assume this object is just being plumbed through chrome and the IPC layer back to WebCore in another process? The first quesiton is whether the WebCore vectors that WebVector wraps are threadsafe. If not, well then you probably need to do the conversion anyway. If they are threadsafe and chrome code doesn't need to understand/manipulate them, then you could directly serialize/deserialize it in the IPC layer and move it around that way. But yeah, if you're touching the data at all in Chrome, you probably want to convert. WebVectors are only for conversion and transport. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
I think the code path in this case is (as you suggest): glue code creates vector of WebMessagePortChannels out of an array of MessagePortChannels. this gets passed down into WebMessagePortChannel.postMessage() WebMessagePortChannelImpl.postMessage() sends it to the right thread, then converts the vector into a vector of port IDs, and sends this to the browser process via IPC. Since we're not really messing around with the vector outside of one or two calls in the glue code, it probably makes sense to just use WebVector from the start, but I'll keep in mind that the recommended approach is to use non-WebKit classes elsewhere and convert as needed when calling WebKit API. Thanks for the help! -atw On Thu, Aug 20, 2009 at 6:35 PM, Jeremy Orlow wrote: > On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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? > > > That's one major benefit. Another one is that WebKit could be built as a > DLL with only a small surface area of entry-points. Another one is that it > forces us to clean up some really messy code and dependencies. > > But probably the biggest benefit is that it "documents" how we're using > WebCore. Once we have a build bot on http://build.webkit.org that builds > with our API, other WebKit developers will be able to see when they break > us. Eventually we'll also be running layout tests against our version of > WebKit+WebCore+V8+SKIA which will do even more "documenting". > > >> 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. >> > > Agreed, but it help with the case of others breaking us. > > >> Anyhow, I'm trying to understand the philosophy around when to use classes >> like WebVector (our WebKit API version of Vector). 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. >> > > Agreed about the slippery slope part. > > I assume this object is just being plumbed through chrome and the IPC layer > back to WebCore in another process? > > The first quesiton is whether the WebCore vectors that WebVector wraps are > threadsafe. If not, well then you probably need to do the conversion > anyway. If they are threadsafe and chrome code doesn't need to > understand/manipulate them, then you could directly serialize/deserialize it > in the IPC layer and move it around that way. > > But yeah, if you're touching the data at all in Chrome, you probably want > to convert. WebVectors are only for conversion and transport. > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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. In some cases, visitor or iterator patterns can be better than a WebVector. See WebHTTPHeaderVisitor and WebPluginListBuilder for examples. -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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote: > On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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. > > In some cases, visitor or iterator patterns can be better than a WebVector. > See WebHTTPHeaderVisitor and WebPluginListBuilder for examples. > > -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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
I noticed that you haven't done any WebKit merges yet? ;-) Kidding aside, this effort is about translating webkit/glue into a stable API that we can live with. We built webkit/glue originally to shield the majority of the Chromium code base from the constant churn of WebCore. It helped reduce the cost of merging because the set of required changes on our end were generally limited to the implementation of webkit/glue. In a few cases, WebCore changed too drastically, which necessitated an API change at the webkit/glue level, but those were the exception not the norm. Now, if we had really been planning for the future, we would have written webkit/glue using WebKit style and with minimal dependencies back onto the Chromium code base. Unfortunately, we did not do that, and so we are left having to do that work now. webkit/api is that work in progress. It should be complete by end-of-quarter. Of course, if your work is primarily about changing WebCore interfaces that the embedder must implement, then those changes will have a corresponding WebKit API change. That's just life. Consider such cases the cost of said shield. Once WebKit API is upstreamed, other contributors to WebKit will be able to help maintain it. If a WebCore interface changes in a superficial manner (name changes, etc.), then engineers who know nothing about Chromium will be able to keep our port alive just as they can do today for the Qt port, for instance. By the way, other ports have WebKit APIs too and for the same reasons :-) -Darin On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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'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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote: > On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote: > >> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote: > > > On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote: > >> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote: >> >>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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. > Yes. I think you have to use WebVector in this case. It sounds like you could probably do without any copies if you add a helper method or two in the API to directly serialize it to something suitable for IPC. The other option is to add some methods to it for iterating. I think either of these could be done without making the implementation overly heavy-weight. > > >> >>> 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? > We don't have anything like this in the API and so far we've been pretty OK without it. Just document transfers of ownership in the comments for methods and try to keep things as simple and intuitive as possible. > > >> >>> -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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote: > 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? > scoped_ptr<> is the Chromium equivalent of WTF::OwnPtr, but I don't think there's an equivalent to WTF::PassOwnPtr. (/cue someone correcting my ignorance) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 10:58 PM, Peter Kasting wrote: > On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote: > >> 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? >> > > scoped_ptr<> is the Chromium equivalent of WTF::OwnPtr, but I don't think > there's an equivalent to WTF::PassOwnPtr. (/cue someone correcting my > ignorance) > This is correct (as far as I know) for Chromium code, but we can't use either in the WebKit API public interfaces (webkit/api/public). Feel free to use any of the WebCore types in the WebKit API implementation though (webkit/api/src). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
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 wrote: > > > On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote: > >> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote: >> >>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
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 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 wrote: > >> >> >> On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote: >> >>> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote: >>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson 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 -~--~~~~--~~--~--~---
