WebCore blob hacking

WebCore blob hacking

Added BlobDataHandle, a thread safe layer of indirection between Blob instances and the underying data.

Change blob processing/handling classes to work with BlobDataHandles insead of URLs.
-- WebCore::Blob
-- WebCore::BlobBuilder
-- postMessage() plumbing
-- WebSocket.send() plumbing
-- fileWriter.write() plumbing
-- SerializedScriptValue
-- FormData

Switched to using string uuids instead of urls in structs and params in the WebKit API.
-- WebBlobData::Item
-- WebHTTPBody::Element
-- WebFileWriter::write()
-- WebBlobRegistry

Removed main thread bridging from BlobRegistry control flow for blobs (not for streams).

Got more explicit about naming: FileSystemURL vs BlobUUID vs PublicBlobURL.

TBR=abarth
BUG=174200
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=159636

[michaeln, 2013-10-15 00:34:43]

see https://codereview.chromium.org/23992003/ for review history

[commit-bot: I haz the power, 2013-10-15 00:35:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/26435003/1

[commit-bot: I haz the power, 2013-10-15 03:30:06]

Change committed as 159636

[kinuko, 2013-10-20 09:27:32]

https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
File Source/core/fileapi/BlobRegistry.cpp (right):

https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
Source/core/fileapi/BlobRegistry.cpp:107: return
WebKit::Platform::current()->blobRegistry();
Sorry for post-commit comments, this question just came up to me now...

The chromium code lazily creates blobRegistry by checking if it's already
created or not and the code doesn't look thread safe to me.  Should we stop
lazily creating the registry or return thread-local registry?

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...

[michaeln, 2013-10-22 02:38:52]

https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
File Source/core/fileapi/BlobRegistry.cpp (right):

https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
Source/core/fileapi/BlobRegistry.cpp:107: return
WebKit::Platform::current()->blobRegistry();
Thnx for pointing that out, I'll post a change to address it.

I see the ThreadSpecificInstance stuff for WebFileSystemImpl, but i think i
prefer the simplicity of constructing it in the ctor. Unlike webfilesystemimpl,
webblobregistryimpl really is stateless.

[kinuko, 2013-10-22 02:40:31]

On 2013/10/22 02:38:52, michaeln wrote:
>
https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
> File Source/core/fileapi/BlobRegistry.cpp (right):
> 
>
https://codereview.chromium.org/26435003/diff/1/Source/core/fileapi/BlobRegis...
> Source/core/fileapi/BlobRegistry.cpp:107: return
> WebKit::Platform::current()->blobRegistry();
> Thnx for pointing that out, I'll post a change to address it.
> 
> I see the ThreadSpecificInstance stuff for WebFileSystemImpl, but i think i
> prefer the simplicity of constructing it in the ctor. Unlike
webfilesystemimpl,
> webblobregistryimpl really is stateless.

Creating it in ctor sgtm, thx!