[Webkit-unassigned] [Bug 43151] Add WebKit API for HTML5 FileSystem API

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Aug 11 20:47:57 PDT 2010


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


Kinuko Yasuda <kinuko at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ericu at chromium.org




--- Comment #12 from Kinuko Yasuda <kinuko at chromium.org>  2010-08-11 20:47:56 PST ---
Updated the patch for minor clean ups.   For now I haven't changed the code for bigger issues - e.g. whether we should merge this into WebFileSystem or not and what name the interface has to be.

(In reply to comment #9)
> (From update of attachment 63139 [details])
> Not sure merging with WebFileSystem is a feature? Do we expect to be able to call WebFileSystem::openFile(path, OpenForRead) to retrieve a FileHandle to a file in the HTML5FileSystem, or call WebFileSystem::makeAllDirectories(x) to a location in the HTML5FileSystem? I don't think thats where we were heading. It may be less confusing to have these segregated. Many of the general purpose interfaces in WebFileSystem are crippled in child processes and fully enabled in the main browser process. In comparison, the HTML5FileSytem APIs only need to be available in child processes.

> WebKit/chromium/public/WebFileSystemCallback.h:37
>  +  template <typename T> class WebVector;
> Looks like WebVector isn't needed here.

Removed.

> WebKit/chromium/public/WebFileSystemCallback.h:43
>  +      // accepted.
> nit: since no line is too long in webkit/webcore... consider unwrapping this comment line

Fixed.

> WebKit/chromium/public/WebFileSystemCallback.h:50
>  +      virtual ~WebFileSystemCallback() {}
> The ownership semantics for this 'callback' class should probably be the same as for the WebAsyncFileSystem::Callbacks, whichever way that tree falls.
> 
> 
> WebKit/chromium/public/WebAsyncFileSystem.h:66
>  +          virtual void onSuccessMetadata(WebFileInfo info) = 0;
> Should this be 
> virtual void onSuccessMetadata(const WebFileInfo& info) = 0;

Fixed.

> WebKit/chromium/public/WebAsyncFileSystem.h:114
>  +      virtual void getDirectory(const WebString& path, bool exclusive, Callbacks*) { WEBKIT_ASSERT_NOT_REACHED(); }
> Should this be createDirectory() for symmetry with createFile()?

Exactly!  Fixed.

> WebKit/chromium/public/WebAsyncFileSystem.h:119
>  +      virtual void isFile(const WebString& path, Callbacks*) { WEBKIT_ASSERT_NOT_REACHED(); }
> I wonder if isDirectory and isFile could/should be subsumed by getMetaData?

Making them integrated into getMetadata would make sense too but I wonder if they may have a little bit different usages.   In this patch I changed their names to fileExists and directoryExists.

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