[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 #32 from Kinuko Yasuda <kinuko at chromium.org>  2011-02-09 16:05:36 PST ---
(From update of attachment 81663)
View in context: https://bugs.webkit.org/attachment.cgi?id=81663&action=review

>>> Source/WebCore/fileapi/Entry.cpp:97
>>> +    return uriBuilder.toString();
>> 
>> Somehow it didn't come to me up until now, but shouldn't we put this in EntryBase (base class of Entry and EntrySync) rather than in Entry?
>> The spec seems to have toURI method also in EntrySync.
>> http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#widl-EntrySync-toURI
>> 
>> And as for string constants, you're right about AsyncFileSystem (its .cpp is not referred in chromium build).  In addition to the fact you pointed out, the URI stuff is not platform dependent stuff but spec based fact, so we should put them in WebCore/fileapi as a common implementation.
>> If we're going to put this code in EntryBase, I'd think about putting the constants in DOMFileSystemBase.{h,cpp}.
>> Or if we're sure we won't use the constants from anywhere else in webcore, it'd be also ok to leave them as literals.
>> So my take is to put them in DOMFileSystemBase or just leave them as is.
>> Thanks for taking your extra time on this issue!
> 
> Hooking this up to EntrySync will require a bit more work, since neither EntryBase nor EntrySync currently have access to the scriptExecutionContext->securityOrigin(). Getting EntryBase access to that would make this patch significantly bigger, I fear.  Might it make sense to do that in a followup?

I see, yes it makes sense.  Let's do it separately.

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