Re: [webkit-dev] Blob will support ArrayBufferView instead of ArrayBuffer for Constructor Parameters
Hi, I haven't been closely following the thread on public-webapps, but looks like ArrayBuffer is back again: http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob It was certainly not there in spec 20120712: http://www.w3.org/TR/2012/WD-FileAPI-20120712/#dfn-Blob But added back when it's updated to take sequence http://www.w3.org/TR/2012/WD-FileAPI-20121025/#dfn-Blob Currently it still works on WebKit but we show a deprecation warning on console. Should we remove the warning? On Tue, Jun 5, 2012 at 9:17 PM, Yin, Li li@intel.com wrote: Okay, I updated the patch, currently, it supports both of ArrayBuffer and ArrayBufferView. And I have filed a new bug about removing support of ArrayBuffer. https://bugs.webkit.org/show_bug.cgi?id=88389 Thanks for your good comments. -- Li Yin -Original Message- From: Kenneth Russell [mailto:k...@google.com] Sent: Wednesday, June 06, 2012 5:21 AM To: Takashi Toyoshima Cc: Yin, Li; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Blob will support ArrayBufferView instead of ArrayBuffer for Constructor Parameters I think that WebKit should continue to support the old constructor for a brief period of time, but warn about its use. I've commented on the patch indicating this. Li Yin, if you implement this, please file a follow-on bug about removing support for the old constructor. The new bug should depend on the old, and it would be nice if you would own the follow-on bug. -Ken On Tue, Jun 5, 2012 at 7:33 AM, Takashi Toyoshima toyos...@google.com wrote: Hi, The same change will happen in XHR and WebSocket. I suggest to keep on holding ArrayBuffer interface in the WebSocket API spec at the thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263 From the discussion, IE seems to continue supporting ArrayBuffer at least for WebSocket. So, I think WebKit also should continue to support it in addition to ArrayBufferView. Thanks, On Tue, Jun 5, 2012 at 9:32 PM, Yin, Li li@intel.com wrote: Hi, From FileAPI Spec: http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob Blob should support ArrayBufferView instead of ArrayBuffer for Constructor Parameters. There is a bug in WebKit to track this issue. https://bugs.webkit.org/show_bug.cgi?id=88294 I have submitted patch to do that already. Any comments are appreciated. Thanks, Li Yin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Takashi Toyoshima Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?
As a quick follow-up, in Chrome 21 the usage histogram tells ~80% of slice call is still using webkitSlice (no wonder as unprefixed slice was rolled out just half a month ago). Since we started showing a deprecation message I hope the number changes over time. slice usage: 22.61% webkitSlice usage: 77.39% On Mon, Jun 11, 2012 at 3:55 PM, Kinuko Yasuda kin...@chromium.org wrote: On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote: Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. We've been shipping the prefixed version for a year now (in Chrome 11-19 and in Safari 5), so I propose keeping the prefixed version too for now, but to start showing a deprecation message to encourage migration. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda kin...@chromium.orgwrote: Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixing Blob.webkitSlice() ?
Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?
On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote: Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. We've been shipping the prefixed version for a year now (in Chrome 11-19 and in Safari 5), so I propose keeping the prefixed version too for now, but to start showing a deprecation message to encourage migration. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda kin...@chromium.orgwrote: Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding File/DirectoryEntry access support for drag-and-drop (if ENABLE(FILE_SYSTEM))
Hi WebKit-dev folks,
Last year I proposed [1] adding support to access dropped/selected
files/directories
via {File,Directory}Entry defined in FileSystem API [2] for better
directory drag-
and-drop support. The proposal got positive feedbacks in general and
I would like to land the changes that expose the feature to experiment this.
[1] Proposal thread on whatwg:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html
[2] File API: Directories and System http://www.w3.org/TR/file-system-api/
To be more specific, I am adding following two APIs:
1) DataTransferItem.getAsEntry() (.webkitGetAsEntry()) for giving access
to Entry's for dropped files/directories via native HTML5 DnD, and
2) HTMLInputElement.entries (.webkitEntries) for input type=file tag.
They are enabled if and only if FILE_SYSTEM flag is enabled.
Most changes are / will be placed under WebCore/Modules/filesystem
or in platform-specific code, though some changes ( 100 lines) need to be
made in the common code.
Umbrella bug: https://bugs.webkit.org/show_bug.cgi?id=76809
Any comments are welcome.
For some more context:
Currently WebKit supports directory drag-and-drop via input using
'webkitdirectory' experimental attribute (iff DIRECTORY_UPLOAD is
enabled),
but it requires a full recursive directory traversal in advance to find
all the
subdirs/files, which could slow down responsiveness and could cause
bad user experience.
We (and some of people who supported the idea on whatwg) think
DirectoryEntry's asynchronous API has a big advantage in such situation
and would like to experiment it.
Thanks,
Kinuko
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_FILE_SYSTEM for FileSystem API support to WebCore
Hi Webkit-dev folks, I wanted to let you know that we have been working on and adding code for FileSystem API [1] to WebKit. (I think I have mentioned the feature several times in the past on this mailing list but have never sent out an announce or request-for-comments type email so far.) The feature/API builds on top of the core File API [2] and it is behind the ENABLE_FILE_SYSTEM feature define. Right now the feature is enabled by default in chrome/chromium port and being tested on buildbots. An umbrella bug for this feature is/was: https://bugs.webkit.org/show_bug.cgi?id=42903 Right now the only port that implements this feature is chrome/chromium (as far as I know), but we have a plan to add Mac port support too in the near future (if no one objects), and we expect this feature to be eventually enabled by all ports. Looking forward to you comments! Thanks, Kinuko [1] http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ [2] http://www.w3.org/TR/2009/WD-FileAPI-20091117/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_QUOTA for unified quota support to WebCore
On Sat, May 7, 2011 at 9:26 AM, Maciej Stachowiak m...@apple.com wrote: On May 6, 2011, at 1:53 AM, Kinuko Yasuda wrote: Hi webkit-dev folks, I wanted to let you know that I plan to add (and have added some code for) unified storage quota API to WebKit. The feature/API is to allow webapps to request or query per-origin storage quota across multiple storage types (e.g. IndexedDB, SQL DB and FileSystem API). The feature/API has not been fully specified yet but has been discussed on public-webapps and seems to be getting some supports from browser vendors: https://bugs.webkit.org/show_bug.cgi?id=60355 I think you accidentally pasted the WebKit bug URL an extra time, instead of the mailing list discussion link. Oops, right... here's the correct URL for the public discussion: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0346.html Thanks, Kinuko - Maciej I'd like to move this forward and start experimenting the API in WebKit. This support will be behind the ENABLE_QUOTA feature define and the exposed API will be vendor-prefixed as the API is still in its very early stage. Here's the umbrella bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=60355 I plan to add a common interface in the WebCore codebase and then to add implementation for chromium port first so that the chromium buildbots will be tracking ENABLE_QUOTA build. We expect this feature/API to be eventually fully specified and enabled by all ports. Looking forward to your comments. Thanks, Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_QUOTA for unified quota support to WebCore
Hi webkit-dev folks, I wanted to let you know that I plan to add (and have added some code for) unified storage quota API to WebKit. The feature/API is to allow webapps to request or query per-origin storage quota across multiple storage types (e.g. IndexedDB, SQL DB and FileSystem API). The feature/API has not been fully specified yet but has been discussed on public-webapps and seems to be getting some supports from browser vendors: https://bugs.webkit.org/show_bug.cgi?id=60355 I'd like to move this forward and start experimenting the API in WebKit. This support will be behind the ENABLE_QUOTA feature define and the exposed API will be vendor-prefixed as the API is still in its very early stage. Here's the umbrella bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=60355 I plan to add a common interface in the WebCore codebase and then to add implementation for chromium port first so that the chromium buildbots will be tracking ENABLE_QUOTA build. We expect this feature/API to be eventually fully specified and enabled by all ports. Looking forward to your comments. Thanks, Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC binding code question
On Tue, Sep 28, 2010 at 11:02 PM, Maciej Stachowiak m...@apple.com wrote:
And what I have written for this is like following:
if (!exec-argument(1).isNull() !exec-argument(1).isUndefined()
exec-argument(1).isObject()
!exec-argument(1).inherits(JSFlags::s_info)) {
JSObject* object = exec-argument(1).getObject();
flags = Flags::create();
JSValue jsCreate = object-get(exec, Identifier(exec, create));
flags-setCreate(jsCreate.toBoolean(exec));
JSValue jsExclusive = object-get(exec, Identifier(exec,
exclusive));
flags-setExclusive(jsExclusive.toBoolean(exec));
}
Basically the code calls JSObject::get() to get values for the given
property names.
This looked straightforward, but I was told that the get(exec)
re-enters Javascript and could do any arbitrary thing.
This much is true. In principle, any property can be a getter, so get() could
re-enter into arbitrary JS code.
This means that during the get() even the parameter object or the
calling object (imp) may get deallocated.
This part, I think not. As long as they are referenced by currently executing
code (either by JS or by the machine stack via a local variable) they won't
get deallocated.
Ah... that sounds right. They must be referenced by the executing code/context.
That being said, others may have suggestions for better ways to code this.
Perhaps Geoff or Oliver have suggestions.
I'll try digging this a bit more (for myself) and will upload a patch
like that, but if anyone has suggestions for better ways I'd be very
glad to change/improve it.
So here I have two questions:
1) How can I write a safe binding code that reads JSON-format
parameters? Is there some recommended way or any good idea?
2) I saw several other code doing the same/similar thing as I do
(calling JSObject::get()) to get arbitrary parameter values.
Are they safe? Is there a guarantee that the code executed during
get() doesn't deallocate some objects?
Nothing that has a live reference to it will get collected, and there's no
such thing as explicit deallocation in JS.
Makes sense, all the objects must be deallocated in that way.
Thanks very much!
Kinuko
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JSC binding code question
Hi Webkit folks,
I'm writing a JSC binding code (custom binding code for now) for a
method that can take JSON-format parameters, and I want to know what
would be the right/recommended way.
I mean, I want to write a binding code that can executes javascript code like:
directoryEntry.getFile(lockfile.txt, {create: true, exclusive: true});
Where the getFile() method is defined as:
interface DirectoryEntry : Entry {
void getFile(in DOMString path, in Flags flags, /* ... */);
};
interface Flags {
attribute boolean create;
attribute boolean exclusive;
};
(They are from the File API: Directories and System's draft [1])
And what I have written for this is like following:
if (!exec-argument(1).isNull() !exec-argument(1).isUndefined()
exec-argument(1).isObject()
!exec-argument(1).inherits(JSFlags::s_info)) {
JSObject* object = exec-argument(1).getObject();
flags = Flags::create();
JSValue jsCreate = object-get(exec, Identifier(exec, create));
flags-setCreate(jsCreate.toBoolean(exec));
JSValue jsExclusive = object-get(exec, Identifier(exec, exclusive));
flags-setExclusive(jsExclusive.toBoolean(exec));
}
Basically the code calls JSObject::get() to get values for the given
property names.
This looked straightforward, but I was told that the get(exec)
re-enters Javascript and could do any arbitrary thing.
This means that during the get() even the parameter object or the
calling object (imp) may get deallocated.
So here I have two questions:
1) How can I write a safe binding code that reads JSON-format
parameters? Is there some recommended way or any good idea?
2) I saw several other code doing the same/similar thing as I do
(calling JSObject::get()) to get arbitrary parameter values.
Are they safe? Is there a guarantee that the code executed during
get() doesn't deallocate some objects?
Any help/suggestions/comments would be highly appreciated.
Thanks!
Kinuko
[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
[2]
http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDirectoryEntryCustom.cpp
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. There are some more files... I'll make a cl to move them to WebCore/fileapi. Thanks, Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
(Sending from the right address) We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? On Fri, Aug 27, 2010 at 6:01 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 27, 2010, at 5:15 PM, Adam Barth wrote: On Fri, Aug 27, 2010 at 4:08 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 27, 2010, at 3:55 PM, Adam Barth wrote: Looking through WebCore/html I noticed the files below. I'm not sure they belong in WebCore/html because they don't appear to be HTML-specific. Rather, they seem like generic web platform APIs (e.g., they could be exposed to SVG or whatever other markup languages we choose to support in the future). Should we move these to WebCore/page, WebCore/dom, or should we make a new location for these sorts of things? I think the File API (which all of these are related to) deserves its own directory right under WebCore. Ok. I can take care of that. Thoughts on names? WebCore/file ? I would say file-api or fileapi or something, since it seems more likely than other cases to get confused with the general concept of files. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] FileAPI/FileWriter support
On Thu, Mar 25, 2010 at 12:44 PM, Dmitry Titov dim...@chromium.org wrote: I'm curious what the ByteStore object is for? While reading the document, I've got an impression that BlobBuilder would store all content of the blob under construction in that store, 'realizing' the parts (encoding the strings into utf-8 and reading the files underlying Blobs). It seems to be better to avoid 'realizing' the separate strings/blobs until the very end (basically, until the bits are needed for actual XHR.send() or FileWriter.write()), otherwise BlobBuilder.append() becomes a synchronous read whole file operation. I agree that 'realizing' should be avoided until the very end, and I'm thinking to make BlobBuilder behave like that. In my rough plan / early prototype, ByteStore represents an internal buffer that can grow while Blob represents a 'snapshot' of a buffer. A Blob can have either one of a file, a ByteStore or a list of Blobs (described below) as its backing store and there can be multiple Blobs with different (start, length) for a same ByteStore. BlobBuilder holds a list of references of what have been appended. In typical cases it has a list of Blobs, and it returns a special form of Blob called CombinedBlob, that holds a list of Blobs as its backing store (so at that point the data is still not in its 'realized' format). In simpler cases it may just store only one ByteStore, and it just returns a plain Blob snapshot for the ByteStore. When we need to get the contents of a Blob, we read out its contents and 'realize' it as an actual bytes array, so this should occur really at the end of the process. If a Blob was of CombinedBlob we recursively call its 'read' method to get the data. (This design was largely inspired by that of gear's implementation) Does that sound make sense? Any suggestions would be appreciated. Kinuko Dmitry On Wed, Mar 24, 2010 at 5:42 PM, Kinuko Yasuda kin...@chromium.orgwrote: Hi webkit-dev folks, I'm working on FileAPI/FileWriter support and would like to start making changes / send patches for the work. Our initial target platform is chromium and many of the changes will only touch files under platform/chromium, but I will also change existing Blob/File code and will add some modules in WebCore for async file operations. Here's the design doc (implementation plan) for FileWriter: http://docs.google.com/View?docID=0AWoCez0NQ60KZG5jaGhkZ18xZ25rZ3RxY3Arevision=_latesthgd=1 The plan/design is not concrete yet and any feedbacks are more than welcome. To start with, I'm planning to open a new meta issue for FileWriter (will also update webkit.org/b/32624) and start submitting changes in small pieces whenever possible. Thanks! Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] FileAPI/FileWriter support
Hi webkit-dev folks, I'm working on FileAPI/FileWriter support and would like to start making changes / send patches for the work. Our initial target platform is chromium and many of the changes will only touch files under platform/chromium, but I will also change existing Blob/File code and will add some modules in WebCore for async file operations. Here's the design doc (implementation plan) for FileWriter: http://docs.google.com/View?docID=0AWoCez0NQ60KZG5jaGhkZ18xZ25rZ3RxY3Arevision=_latesthgd=1 The plan/design is not concrete yet and any feedbacks are more than welcome. To start with, I'm planning to open a new meta issue for FileWriter (will also update webkit.org/b/32624) and start submitting changes in small pieces whenever possible. Thanks! Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
