Hi, All, Crosswalk is based on Chromium. Native File API is based on Isolated File System of Chromium. Currently, all Chromium file APIs use callback. The implementation will be more straight forward, if we use callback function. In my opinion, Native File API should align with other Chromium file APIs. When Google changes file APIs to Promise, we change Native File API to Promise at that time.
Thanks, Shawn From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] Sent: Friday, March 14, 2014 8:17 PM To: Kostiainen, Anssi Cc: Gao, Shawn; Santos, Thiago; crosswalk-dev@lists.crosswalk-project.org Subject: Re: [Crosswalk-dev] Intent to Implement - Native File API I also support basing our work of the Mozilla spec Kenneth On Fri, Mar 14, 2014 at 11:14 AM, Kostiainen, Anssi <anssi.kostiai...@intel.com<mailto:anssi.kostiai...@intel.com>> wrote: Hi Shawn, Thiago, All, The current standardization status (no change since 31 Jan) of the various file system APIs may be of interest to you: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0164.html In short, there is no consensus yet among browser vendors, and thus no single API that would be broadly implemented. Given the current state, my guidance would be to implement any API that addresses the requirements you have, and while doing so document the delta to the spec you reuse, any issues found, so that we can inform the related standards work. Personally I think the "FileSystem API” proposal (http://w3c.github.io/filesystem-api/Overview.html) by Mozilla is more aligned with the current API design best practices (e.g. Promises instead of callbacks), but AFAICT no-one, not even Mozilla, has shipped it yet. Also in terms of standards maturity it is an early draft. The showstopper for you is that it’s a sandboxed file system. That said, web developers seem to be in favour of the Promises-based API, as we’re getting feedback such as the following from web developers: [[ The callback-based approach of the Google proposal let us end up in callback hell right from the start, so we wrapped the whole API in promises as best as we could, just to make it usable for our app developers. In that department, Mozilla’s promises-based proposal might be much cleaner and easier to work with. http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0198.html ]] By implementing and shipping the feature in Crosswalk regardless of the shape of the API we are able to gather further feedback from web developers using the API. Thanks, -Anssi On 13 Mar 2014, at 14:56, Thiago Marcos P. Santos <thiago.san...@intel.com<mailto:thiago.san...@intel.com>> wrote: > LGTM, let me know if I can help on something. > > Would be good to have this API on all the platforms we support. > > On 03-03-2014 12:11, Gao, Shawn wrote: >> *Description:* >> Native file API allows web app developer to read, write and enumerate >> native file system via JavaScript. From Webapp developer perspective, >> most of interfaces in W3C _File API: Directories and System_ >> <http://www.w3.org/TR/file-system-api/> [1] and_File API: Writer_ >> <http://www.w3.org/TR/file-writer-api/>[2] will be reused. For example, >> FileEntry, DirectoryEntry, FileWriter, etc. >> In Chromium technical scope, there are two related file system API: W3C >> file API[1][2] and _Chrome extension file API_ >> <http://developer.chrome.com/apps/app_storage>[3]. Neither one can >> satisfy above requirements: >> >> 1. W3C file API is sandbox file system. >> 2. Chrome extension file API is only available on top of chrome >> extension, which won’t support on Crosswalk. Secondly, it pops up >> file chooser dialog each time for security concern. >> >> *Affected component:* >> >> 1. xwalk/runtime/renderer/ >> >> Add code here to handle JavaScript function call to Isolated File System >> API. Send Isolated File System requests to browser process through IPC. >> >> 2. xwalk/runtime/browser/ >> >> Handle Isolated File System requests from render process >> >> 3. xwalk/experimental/ >> >> Inject Isolated File System JavaScript code to render via xwalk >> extension mechanism. >> *Related feature: * >> _https://crosswalk-project.org/jira/browse/XWALK-672_ >> *Target Release:*** >> Crosswalk 6 >> *Implementation details:* >> The implementaion is build on top of ”Isolated File System”, which is >> used by Chrome extension file API as well. Blink already have Isolated >> File System support. So, I can use it to create FileSystem object in >> Javascript context with out modify upstream Blink code. Then, I am going >> to follow the Chrome extesnion file API way to implement Crosswalk >> native file system. >> File System Design Chart: >> Limitations: >> ======== >> >> 1. Linux, Tizen and Android will be supportted. Windows and MacOS are >> not condidered. >> 2. Sync file API is not included in this feature. >> >> Security consideration: >> ================= >> >> 1. For Linux and Tizen: reply on Crosswalk extension security machanism. >> 2. For Andoid: WRITE_EXTERNAL_STORAGE and MOUNT_UNMOUNT_FILESYSTEMS >> need to be declared in the activity manifest. >> >> IDL: >> === >> /[Supplemental, NoInterfaceObject]/ >> /interface FileSystem {/ >> /void //_requestNativeFileSystem_/ >> <http://www.w3.org/TR/file-system-api/>/(DOMString path, >> //_FileSystemCallback_/ >> <http://www.w3.org/TR/file-system-api/>/successCallback, optional >> //_ErrorCallback_/ <http://www.w3.org/TR/file-system-api/>/errorCallback);/ >> /};/ >> Description: >> Requests a native filesystem in which to store application data.If >> successful, this function must give access to a native files ystem, as >> defined above. >> Paramters: >> +----------------+--------------------+---------+--------+-----------------------------------+ >> |Parameter | Type |Nullable |Optional| >> Description | >> +----------------+--------------------+---------+--------+-----------------------------------+ >> |path | DOMString | no | no |The real path >> on native system | >> +----------------+--------------------+---------+--------+-----------------------------------+ >> |successCallback | FileSystemCallback | no | no |The callback >> that is called when | >> | | | | |user agent >> provides a file system | >> +----------------+--------------------+---------+--------+-----------------------------------+ >> |errorCallback | ErrorCallback | no | yes |A callback >> that is called when | >> | | | | |errors >> happend, or when the reqeust| >> | | | | |to obtain the >> filesystem is denied | >> +----------------+--------------------+---------+--------+-----------------------------------+ >> >> Return Type: void >> More background: >> ============== >> There are two options were discussed before, neither are accepted with >> reasons. >> >> 1. Improve file API in Blink to support out-of-sandbox file access. >> Abondoneded because of maintainence concern. >> 2. Implement a new file API that expose the C file API interface. >> Abondoneded because incompatible with W3C file interfaces. >> >> *References:* >> */[1] /**/_http://www.w3.org/TR/file-system-api/_/* >> */[2]/**//**/_http://www.w3.org/TR/file-writer-api/_/* >> */[3] /**/_http://developer.chrome.com/apps/app_storage_/* >> Thanks, >> -Shawn > > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org> > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
