On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <[email protected]>wrote:
> +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' > Actually, Dumi's case is slightly different. He wants to get SecurityOrigin::databaseIdentifier, right? Maybe WebSecurityOrigin should have a databaseIdentifier() method that outputs a FilePath object? ... 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? > WebCore::SecurityOrigin handles these for us. I'll make it difficult for a base::SecurityOrigin to be constructed any way besides it coming from WebKit::WebSecurityOrigin (which only comes from WebCore::WebSecurityOrigin). We can then deal with these details only if/when we need to. 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 -~----------~----~----~----~------~----~------~--~---
