DISREGARD. This is a duplicate of https://groups.google.com/a/chromium.org/g/blink-dev/c/yNslidDtNho/m/IEPD25X_AAAJ
On Thursday, January 20, 2022 at 9:42:39 AM UTC-8 Austin Sullivan wrote: > Contact emailsasu...@chromium.org, five...@chromium.org, m...@chromium.org > , rs...@chromium.org > > Explainer > https://github.com/WICG/file-system-access/blob/main/AccessHandle.md > > Specification > > Summary > > The Origin Private File System (OPFS, part of the File System Access API) > is augmented with a new surface that brings very performant access to data. > This new surface differs from existing ones by offering in-place and > exclusive write access to a file’s content. This change, along with the > ability to consistently read unflushed modifications and the availability > of a synchronous variant on dedicated workers, significantly improves > performance and unblocks new use cases. > > > Included in this origin trial is also a version of the > FileSystemHandle::move() method, currently limited to files in the OPFS > only. The move() method will be shipped separately with its own intent ( > https://chromestatus.com/feature/5640802622504960), but this limited > subset is included in this origin trial because it significantly improves > the performance and ease of use of the OPFS. > > Blink componentBlink>Storage>FileSystem > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/664 > > TAG review statusPending > > Risks > > > Interoperability and Compatibility > > The feature has to be compatible with existing ways to access data on OPFS > i.e., createWritable() and getFile(). The use of write locks and care for > backwards compatibility should mean that the risk here is low. In order to > ease compatibility concerns in the future, we've added an optional 'mode' > parameter to createAccessHandle()/createSyncAccessHandle(). This allows us > to eventually extend AccessHandle functionality to non-OPFS file systems > without necessarily taking the OPFS behaviour as default (more details > here: > https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems). > > There is a risk of interoperability between vendors, pending the position > on implementing this surface. This design is the result of feedback from > Gecko and WebKit, who reviewed previous iterations of this functionality > and gave feedback that it should integrate more strongly with OPFS. We > believe that the new design, when paired with a separate streams-based > extension to OPFS, meets these goals. However, we have not yet received > work back as to whether they agree with our assessment. > > > Gecko: No signal on official Request for Position ( > https://github.com/mozilla/standards-positions/issues/562), but > supportive of migrating the spec to whatwg ( > https://github.com/whatwg/sg/issues/176). > > WebKit: In development ( > https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html) > Request for position was not answered, but the feature is being implemented > and is available in TP. See reference bug: > https://bugs.webkit.org/show_bug.cgi?id=231185 > > Web developers: No signals > > Other signals: > > > Goals for experimentation > > In general, we want to validate the new surface against "real world" use > cases from our partners and developers at large. In particular, we are > interested in the relative usage between the sync and async methods, since > this could have an impact on performance when using Asyncify. We also would > like to receive qualitative feedback on the ease of use of the API from > within Wasm. > > > Reason this experiment is being extended > > We're working with a partner, but they need more time to test and give > feedback on the API. > > Ongoing technical constraints > > None > > Debuggability > > Basic tooling: Autocomplete works as described in "New WebIDL/DOM > interfaces and attributes". Extended tooling: we'll eventually want to be > able to explore files stored in OPFS. There are two tracking bugs related > to this: crbug.com/256067 and crbug.com/735618. This API doesn't really > add new storage backends, just new ways to interact with files, so we'd be > covered by those as well. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)?No > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?Yes > > DevTrial instructions > https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out > > Flag nameFileSystemAccessAccessHandle > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218431 > > Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1232436 > > Estimated milestones > OriginTrial desktop last 102 > OriginTrial desktop first 95 > DevTrial on desktop 94 > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5702777582911488 > > Links to previous Intent discussionsIntent to prototype: > https://groups.google.com/a/chromium.org/g/blink-dev/c/33T36N6VBKI > Ready for Trial: > https://groups.google.com/a/chromium.org/g/blink-dev/c/_nB5VfgXW_I > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/-FVIvFovd3g/m/vUNm4X8UBAAJ > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f660b36a-8df9-46b7-a2e4-c9c76b3d6b68n%40chromium.org.
