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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jul 30 19:06:46 PDT 2010


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





--- Comment #7 from Kinuko Yasuda <kinuko at chromium.org>  2010-07-30 19:06:46 PST ---
Thanks for the comments.

(In reply to comment #6)
> (From update of attachment 63011 [details])
> well.  In fact, it seems like we should try to unify WebFileSystem and WebAsyncFileSystem
> so that they expose similar APIs, with the exception of WebFileSystem containing only
> synchronous methods whereas WebAsyncFileSystem contains asynchronous methods.
> how about just merging these asynchronous methods into WebFileSystem?

I was afraid mixing up APIs with different security assumptions in a single module would be confusing.
WebFileSystem API has more generic usage than WebAsync one - it implements APIs that are used for misc internal file operations in WebKit.  Basically they don't work in a sandbox environment except for a few APIs that are used for File API and require prior permission on the target paths.

Assumptions for HTML5 FileSystem API are different from WebSyncFileSystem - it's primarily being added for FileSystem API and is going to work only if the target paths are under a certain directory.  In that sense what we're going to add is not a generic async filesystem API but 'HTML5FileSystem'.   Or are we planning to use it for other purpose?

I agree that it would look more natural to have synchronous API and asynchronous API together but at least it would need very clear API documentation in that case.

> WebKit/chromium/public/WebAsyncFileSystem.h:71
>  +          virtual ~Callbacks() { }
> can this destructor be made protected?  i'm assuming that the
> embedder who receives a Callbacks pointer is not expected to
> delete it, so making it protected would enforce that.

Hmm... I thought that just giving the ownership of the pointer to the embedder and having it delete would be easier, but it may not look clean as an exposed API.  In either way I'm going to add clearer comments.

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