[Webkit-unassigned] [Bug 53529] [fileapi] Add support for filesystem: URI handling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=53529





--- Comment #10 from Adam Klein <adamk at chromium.org>  2011-02-01 16:40:07 PST ---
(From update of attachment 80849)
View in context: https://bugs.webkit.org/attachment.cgi?id=80849&action=review

>> Source/WebCore/fileapi/FileSystemURL.h:53
>> +};
> 
> Generally, we don't create classes that have all static members.  What does a FileSystemURL represent?  How is that different from a KURL?

As you guessed, this is simply mirroring the code layout of BlobURL. createURLString() should be able to move entirely to Entry.cpp (it's not called elsewhere).  See my question in SecurityOrigin.cpp about what I should do with getOrigin().

>> Source/WebCore/page/SecurityOrigin.cpp:68
>> +// FIXME: Should this be part of SchemeRegistry?
> 
> Yes.

Will move once we've agreed on a name.

>> Source/WebCore/page/SecurityOrigin.cpp:69
>> +static bool schemeRequiresRequestCapabilityForDisplay(const String& scheme)
> 
> We probably don't want to use the term "Capability" here because Capability has a special meaning in security, and this doesn't quite match that meaning.

I disliked this name too; do you have an alternate suggestion? SchemeRegistry::shouldTreatURLSchemeDisplayAsRequestRestricted?  More words doesn't necessarily make it clearer to me.

>> Source/WebCore/page/SecurityOrigin.cpp:152
>>          return adoptRef(new SecurityOrigin(BlobURL::getOrigin(url), sandboxFlags));
> 
> I see that you're copying the pattern here from BlobURL, but that's not a good pattern.  We should fix Blob URL not to use this style either.

Do you have a pattern in mind?  Should the code that's currently in FileSystemURL::getOrigin() just move into the SecurityOrigin constructor?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.