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.
2. Bolb lives in io_thread of browser process. So, should our extension
live in same thread like StorageInfoProvider in ui_thread?
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?
Thanks,
Shawn
*From:*Oliveira, Caio
*Sent:* Thursday, January 2, 2014 7:50 PM
*To:* Gao, Shawn; [email protected]
*Subject:* RE: The ways to implement native file system api
Hello,
Have you considered implementing this as an extension in C++? I suspect
you are getting some extra overhead to go from C++ to Java and come
back, and it doesn’t seem to me we need any Java specific API do reach
the file system (guessing here).
I suggest you take route #1 for the reasons Mikhail and Thiago already
pointed: for integrating with the permission system in Crosswalk (that
wouldn’t be available to Blink/Chrome code, so we would have to add
tweaks to control this specific permission there) and because we do have
some room for improvement on extension system itself.
Cheers,
Caio
*From:*Crosswalk-dev
[mailto:[email protected]] *On Behalf Of
*Gao, Shawn
*Sent:* Friday, December 27, 2013 9:30 AM
*To:*
[email protected]<mailto:[email protected]>
*Subject:* [Crosswalk-dev] The ways to implement native file system api
Hi, All,
I am working on Native File System Api. See feature description on Jira,
https://crosswalk-project.org/jira/browse/XWALK-672.
There are two options to implement this feature.
1. Take currently crosswalk extension framework to implement native file
system api. Like Contacts and Messaging api.
* The pros, only js and java programming required. Don’t touch any Blink
or Chrome code.
* The cons, It gets */2 times slower/* than option2, Because of base64
encode/decode operation in each js and java side.
Have you tried to use the Internal Extensions way of sending messages
(i.e. base::Value with automatic serialization)? Because that maps to a
size+data pair (see param traits for Value::Binary) and base64 is not
required.
And what is the real need of having to implement the backend in Java?
Can it be done in C++/Linux/POSIX/NDK APIs?
2. Modify code in Blink and Chrome to extend the ability of
requestFileSystem() to access native file system.
* The pros, faster and straightforward for web developer. Reuse the code
for objects like “FileEntry”, etc.
* The cons, Modify Blink and Chrome code may get more risk.
Maybe cannot be accepted by upstream.
Any suggestions are appreciated.
I vote for using the Internal Extensions way of implementing APIs
because of maintainability, better integration with xwalk runtime and
code sharing potential with Tizen.
But I strongly recommend doing it the Internal Extensions, using IDLs,
platform data models when some kind of specialization is needed and
using native code as much as possible. No JSON and thus no base64
enconding will be required if you do this way.
Cheers,
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
