On 23-01-2014 12:19, Gao, Shawn wrote:
Hi, All,
Chromium file api don’t write data directly by write() method. It
leverages “Blob” object. Blob is a v8 type. But Blob instances lives in
io_thread of browser process in fact. When each Blob is create or append
data. The data will be transferred by IPC from render to browser. If
data size exceeds 256k, IPC takes built-in shared memory. If under, it
just copy & paste data. When write() is called, render just send the
uuid of Blob back to browser.Then browser read blob data by this uuid
and write it to file.
Following issues are my opinions. If anything wrong please tell me freely:
1. File api depends on Blob so deeply. So we should reuse Blob type of
Chromium.
You can write a Blob type using a JS Shim. My understanding is Blob is
just a cursor to the actual file living in the backend.
2. Bolb lives in io_thread of browser process. So, should our extension
live in same thread like StorageInfoProvider in ui_thread?
I would probably be fine to have the backend of your Filesystem API in
the Extension Thread. The idea of having it on anything else other than
the UI Thread is so it doesn't not block the UI while waiting for a
read/write().
3. Bolb instances are private member of FileAPIMessageFilter. In
FileAPIMessageFilter::OnWrite(), it gets data by
blob_storage_context_->context()->GetBlobDataFromUUID(blob_uuid);.
Please refer to
src/content/browser/fileapi/fileapi_message_filter.cc:404. So, should we
modify upstream to let our extension get blob data
I still think we should implement this inside Crosswalk.
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
