On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow <jor...@chromium.org> wrote:
> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <micha...@google.com>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?
>
Dumi needs to form file path elements, yes.
Dumi also needs to store a canonical string representation of an 'origin' in
the tracker database which will equate to the canonical string represetation
6 months from now (either that or upgrade the column values whenever that
representation changes). Q: What is the canonical string representation used
in the localstorage.db which has the similar requirement to track things per
origin? Probably WebCore::SecurityOrigin::toString(), is that right?
Those two things probably shouldn't be confounded.
At some point in the not too distant future, we'll need to interrogate from
a ChromeUI database, localstorage, appcache, and (filesystem) for what
'origins' are making how heavy a use of those systems.
An important point is that code today is writing string values, and code 6
months from now has to interpret those values and match against them.
> ... 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.
>
As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a
security origin. I'm not sure, may already have instances of that in the
code base for all I know.
>
>
> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow <jor...@chromium.org> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
