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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 9 10:45:47 PST 2011


--- Comment #31 from Adam Klein <adamk at chromium.org>  2011-02-09 10:45:46 PST ---
(In reply to comment #30)
> (From update of attachment 81663 [details])
> 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

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?

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

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

More information about the webkit-unassigned mailing list