+1 SecurityOrigin class Sounds like a reasonable plan. I suspect there may already be cases where we're actually comparing a chrome generated security origin, as produced by GURL.GetOrigin(), with a webkit generated security origin, as produced by WebSecurityOrigin.toString(). So we may want to accelerate the part of the plan to do more than opaquely pass around and test webkit generated representations.
Also, I think dumi has a use case to crack it open in order to form file path elements of the form 'scheme_host_port' ... and why not use strings? * does the string contain a trailing slash, or not? * in the default port case, does the string contain the default port number or not? On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow <[email protected]> wrote: > Right now, we don't have a good story for what to do with > WebCore::SecurityOrigins in Chromium. We now have a WebSecurityOrigin in > WebKit, but if you want to move the data between processes, you need to > convert it to a string and then send that. In some cases we then convert > the string to a GURL, but this seems like the wrong thing to do (more on > this in a sec). > To me, the right answer is to create a type in base called SecurityOrigin > that wraps a string and does equality checks. The equality checks can be > done as string comparisons since the WebCore::SecurityOrigin::toString() > method canonicalizes it. If, in the future, we need to do anything more > with SecurityOrigins (besides transporting them, testing equality, and using > them in sets/maps) then we can make the class more complex. > > Why not use GURL? For one, the SecurityOrigin has a "null" state which is > significant and which isn't represented in GURL. In addition, there's a lot > of operations you can do with a GURL which don't really make sense in the > context of a SecurityOrigin. Passing around a SecurityOrigin object is also > much more self-documenting. But, the fact that GURL looks like a tempting > way to store a SecurityOrigin is actually one of the biggest reasons why I > think we should make a dedicated type. > > If people agree with this, my plan is to create such a type in base and > modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin. > I'll then convert everything over (or ask people to do the conversion if it > looks scary). Finally, I'll remove WebSecurityOrigin::toString(). > > Does this sound like a good plan? > > J > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
