LGTM, since this is just extending support on M101 and the API shipped in M102.
On Wed, Jun 22, 2022 at 2:11 PM Austin Sullivan <asu...@chromium.org> wrote: > FYI: In order to provide a gapless support on M101 and earlier, we'd like > to extend the OT until October 4th, one week after the M106 stable release. > The API shape will not change on these earlier releases during this time. > > On Friday, February 11, 2022 at 2:21:42 AM UTC-8 Mike West wrote: > >> Hey Emanuel, >> >> With my comments on the storage foundation I2E >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/wDiMaUps4lg/m/kbGs31B5AQAJ> >> in mind, it looks like good, cross-vendor progress is being made on >> refining Access Handles' implementation and specification. There's clear >> engagement from partners who have begun using the feature in ways that give >> us confidence around it's broad shape and performance characteristics, and >> it seems reasonable to me to extend the trial out a bit to give folks time >> to hammer out the remaining details together. >> >> LGTM to extend the experiment to 101. Ideally, that will allow y'all to >> bring the spec into shape, resolve any remaining disagreements about the >> API's behavior, and ensure our implementation matches those decisions. >> >> -mike >> >> >> On Wed, Jan 26, 2022 at 3:47 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> Would you be able to answer the questions Chris asked on the Storage >>> Foundation I2E? They seem relevant here as well. Thanks! :) >>> >>> On Thursday, January 20, 2022 at 4:06:34 PM UTC+1 Emanuel Krivoy wrote: >>> >>>> We’d like to ask for an extension to our Origin Trial, from M99 to >>>> M101. As mentioned in the Storage Foundation I2E >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/enA3o1UvzcE/m/qsaC_2whAQAJ>, >>>> our partner intended to run a final series of tests with the new surface, >>>> giving us a chance for to measure the impact of some of the design >>>> decisions (the effect of a mixed sync/async surface and of all filesystem >>>> operations being async). The tests were postponed and should happen in the >>>> near future, and so we’d like to extend the trial to be able to gather >>>> feedback from them. >>>> >>>> Please find the Chrome Status template below: >>>> >>>> Contact emails >>>> >>>> fived...@chromium.org, r...@chromium.org >>>> >>>> Explainer >>>> >>>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md >>>> >>>> Specification >>>> >>>> WIP Draft: https://github.com/WICG/file-system-access/pull/344 >>>> >>>> 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 (especially for porting existing >>>> IO-heavy applications to WebAssembly). >>>> >>>> This Intent-to-Experiment is only in reference to the sync variant of >>>> the API i.e., the createSyncAccessHandle() method and the >>>> SyncAccessHandle object (only exposed in worker contexts): >>>> >>>> const handle = await file.createSyncAccessHandle(); >>>> >>>> var writtenBytes = handle.write(buffer); >>>> >>>> var readBytes = handle.read(buffer {at: 1}); >>>> >>>> The sync variant is meant to be consumed by low-level entities like >>>> toolchains. We expect application developers to prefer the async API with >>>> its streaming interface which will be shipped later. >>>> >>>> AccessHandles is the new API shape for what was previously called >>>> Storage Foundation API (Intent-to-Experiment: >>>> http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY. >>>> >>>> >>>> Blink component >>>> >>>> Blink>Storage>FileSystem >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> >>>> >>>> TAG review >>>> >>>> https://github.com/w3ctag/design-reviews/issues/664 >>>> >>>> TAG review status >>>> >>>> Closed, positive feedback. >>>> >>>> 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 directly shared documents outlining alternatives considered >>>> <https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec>, >>>> and later our recommendation >>>> <https://docs.google.com/document/d/1g7ZCqZ5NdiU7oqyCpsc2iZ7rRAY1ZXO-9VoG4LfP7fM> >>>> towards this particular API shape. >>>> >>>> >>>> >>>> We believe that the new design, when paired with a separate >>>> streams-based extension to OPFS, meets the goal of more strongly >>>> integrating with the existing surface. However, we have not yet received >>>> replies to the position requests below. >>>> >>>> Gecko: No formal signal, but generally positive reception with >>>> questions about supporting existing surfaces ( >>>> https://github.com/mozilla/standards-positions/issues/562) >>>> >>>> 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: Positive >>>> >>>> From our Storage Foundation OT, we received very positive feedback on >>>> the need for high performance storage, as well as on the general shape of >>>> the API: >>>> >>>> >>>> - >>>> >>>> Adobe’s support statement (about the need for the capability) >>>> <https://github.com/WICG/proposals/issues/10#issuecomment-804145429> >>>> - >>>> >>>> absurd-sql’s mention >>>> >>>> <https://github.com/mozilla/standards-positions/issues/481#issuecomment-898061119> >>>> - >>>> >>>> Reception on Twitter after DevRel announcement >>>> <https://twitter.com/ChromiumDev/status/1405101909757902851> >>>> >>>> >>>> SyncAccessHandles have a very similar shape to the surface that was >>>> exposed in Storage Foundation’s Origin Trial. The current implementation in >>>> Chrome is currently being tested by partners to confirm it is a good >>>> replacement of Storage Foundation for their needs. >>>> >>>> Ergonomics >>>> >>>> As mentioned above, SyncAccessHandles offer a very similar surface to >>>> the one positively received during Storage Foundation’s OT. The main >>>> differences are the migration of file system operations into OPFS and the >>>> asynchronicity of auxiliary methods (i.e. methods other than read and >>>> write). >>>> >>>> Since many of our use cases require good interoperability between this >>>> API and Wasm, we’ve developed an Emscripten file system >>>> <https://github.com/rstz/emscripten-pthreadfs/tree/main/pthreadfs> >>>> that allows ported applications to use SyncAccessHandles. This >>>> simplifies both activation and use, since the API can be accessed through >>>> standard C/C++ file system libraries. >>>> >>>> Security and Privacy >>>> >>>> SyncAccessHandles have received approval for Security and Privacy in >>>> our launch bug >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1232436>. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> File System Access API usage is also reflected in user settings pages >>>> such as chrome://settings/siteData. >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> Yes, we’ve added tests for all new functionality, as well as for the >>>> intersection between this surface and existing parts of OPFS (in particular >>>> for locking semantics). Our test suite is also run against our Incognito >>>> mode implementation, since it is significantly different from the regular >>>> mode one. >>>> >>>> >>>> >>>> wpt.fyi results: wpt.fyi/results/file-system-access >>>> >>>> Is this feature supported on all six Blink platforms? >>>> >>>> No. File System Access API is not currently available on Android or >>>> Android WebView. >>>> >>>> DevTrial instructions >>>> >>>> >>>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out >>>> >>>> Flag name >>>> >>>> FileSystemAccessAccessHandle >>>> >>>> Requires code in //chrome? >>>> >>>> False >>>> >>>> Tracking bug >>>> >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1218431 >>>> >>>> Launch bug >>>> >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1232436 >>>> >>>> Estimated milestones >>>> >>>> OriginTrial desktop last >>>> >>>> 98 >>>> >>>> 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 discussions >>>> >>>> Intent 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/64702163-232b-44f8-8d51-6ab763c7ea0fn%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64702163-232b-44f8-8d51-6ab763c7ea0fn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/a998604b-8436-4caa-8682-6b6f57dc8564n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a998604b-8436-4caa-8682-6b6f57dc8564n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw_v1MJzwrBwPcgHgLgRpYhwWFTiu1ptwkR7pBj36fZCNA%40mail.gmail.com.
