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