Hello, Replying to Mike inline:
https://github.com/WICG/file-system-access/pull/344 doesn't seem to have > moved in the last ~2 weeks, and I don't see a new PR against the WHATWG > spec. What's y'all's timeline for finishing the specification of this > feature? The plan is to create the PR against the spec in WHATWG this week. It should include the changes from the current feedback in the old PR. > Thanks for doing this investigation! It does sound like something we'd > want to resolve before shipping, as it would be unfortunate for this to > present a barrier to interop. > > I didn't see a bug filed against webkit in a quick search, can you follow > up on that (or point it out if I missed it)? I directly followed up with WebKit and the Storage team. The result of the discussions was that, to avoid compatibility issues with Safari and leave the design of the options object fully open, we should temporarily remove the options parameter from createSyncAccessHandle(). Once there is consensus on how options should be handled, it should be easy to add them back. We would end up in the desired final state, but with an inverted default: the OPFS Access Handle behavior is the default one, and specific options would be needed to use them in other file systems. Since the OPFS use case is the one that has been proven with trials, and the one that other browsers intend to implement for now, I think it makes sense to leave it as the default. To all: Since we have to do code changes to remove the options object, and since the spec still has to be rebased, I wanted to change this request from shipment on 101 to a gapless shipment on 102. I’ll keep working on those two pending items and ping this thread when they are done. Thanks! Emanuel On Wed, Mar 30, 2022 at 3:01 PM Mike West <mk...@chromium.org> wrote: > On Wed, Mar 23, 2022 at 5:48 PM Emanuel Krivoy <fived...@chromium.org> > wrote: > >> Hey Yoav, >> >> >>> So the plan is to land the PR in WICG, and then (immediately) move it >>> over to https://fs.spec.whatwg.org/? >>> What are the current blockers for the WICG PR from landing? >>> >> >> My plan would be to act on the current round of feedback in the WICG PR >> and then move the spec to its final home in WHATWG to finish the >> review/merge there. >> The situation is an artifact of me wanting to do a quick round of >> feedback before investing time in the rebase, just to make sure the spec >> was going in the right direction. Now I think it might have made things >> more confusing than they should have been, sorry! >> > > https://github.com/WICG/file-system-access/pull/344 doesn't seem to have > moved in the last ~2 weeks, and I don't see a new PR against the WHATWG > spec. What's y'all's timeline for finishing the specification of this > feature? > > Have you tried running STP against the WPT test suite? That could be >>> reassuring interop-wise >>> >> >> Thanks for the suggestion. After running the WPTs, there seems to be some >> divergence with the proposed spec. The most substantial one (beyond some >> issues around the type of error thrown) is that the implementation of >> createSyncAccessHandle in Safari TP does not take an options parameter. >> >> The options parameter is there to (eventually) allow using access handles >> on other filesystems (i.e., from outside OPFS, in particular on files >> hosted in the local file system). This feature has been requested by >> developers on various occasions, and would make the File System Access API >> more flexible. In our implementation, the options parameter is required (as >> in, has to be provided when calling createSyncAccessHandle) to avoid >> setting the default behavior of access handles to the particular one needed >> within OPFS. Further context can be found in >> https://github.com/whatwg/fs/issues/19. >> >> I will go ahead and file the appropriate bugs/contact the feature owner! >> > > Thanks for doing this investigation! It does sound like something we'd > want to resolve before shipping, as it would be unfortunate for this to > present a barrier to interop. > > I didn't see a bug filed against webkit in a quick search, can you follow > up on that (or point it out if I missed it)? > > Thanks! > > -mike > > >> >> On Wed, Mar 23, 2022 at 5:39 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> Thanks for working on this important capability!! >>> >>> On Tuesday, March 22, 2022 at 5:24:08 PM UTC+1 Emanuel Krivoy wrote: >>> >>>> Hello blink-dev, We'd like to request a review on our intent to ship >>>> Access Handles with Chrome 101. Since we don't envision changes to the >>>> surface and it is currently in use by Photoshop web, this request comes one >>>> release before our OT expires. Please find the details below: >>>> Contact emails >>>> >>>> fived...@chromium.org, r...@chromium.org >>>> >>>> Explainer >>>> >>>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md >>>> >>>> Specification >>>> >>>> Out for review. >>>> <https://github.com/WICG/file-system-access/pull/344/files> Will be >>>> moved <https://github.com/WICG/file-system-access/issues/342> to >>>> WHATWG after replying to pending comments. >>>> >>> >>> So the plan is to land the PR in WICG, and then (immediately) move it >>> over to https://fs.spec.whatwg.org/? >>> What are the current blockers for the WICG PR from landing? >>> >>> >>>> 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-Ship 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 >>>> >>>> Issues addressed >>>> >>>> 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: Worth Prototyping ( >>>> 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 >>>> >>> >>> Have you tried running STP against the WPT test suite? That could be >>> reassuring interop-wise >>> >>> >>>> >>>> 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> >>>> >>>> >>> Thanks for a very strong developer signal! >>> >>> >>>> >>>> SyncAccessHandles have a very similar shape to the surface that was >>>> exposed in Storage Foundation’s Origin Trial. It is currently a critical >>>> dependency <https://web.dev/ps-on-the-web/#high-performance-storage> >>>> of Photoshop Web. The Photoshop team has confirmed that the current surface >>>> covers their needs and that they have no pending feedback/requests. >>>> >>>> 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>. >>>> >>>> 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, e.g., we’ve >>>> made sure that locking between writables and access handles is correct. >>>> >>>> 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?label=master&label=experimental&aligned >>>> >>>> Is this feature supported on all six Blink platforms? >>>> >>>> Not yet. File System Access API is not yet available on Android or >>>> Android WebView, but the Storage team has expressed interest >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1011535#c9> in >>>> at least enabling OPFS once there is more usage/cross-browser support. >>>> >>>> Demo >>>> >>>> The API has no UI component. An example code snippet can be found here >>>> <https://github.com/WICG/file-system-access/blob/access-handle-spec/AccessHandle.md#new-data-access-surface> >>>> . >>>> >>>> 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 >>>> >>>> 102 >>>> >>>> OriginTrial desktop first >>>> >>>> 95 >>>> >>>> DevTrial on desktop >>>> >>>> 94 >>>> >>>> We aim to ship with 101. >>>> >>>> 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 >>>> >>>> Intent to Extend Experiment: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGL4tBM-mH%2B-Cm7YtBiVMLLGrPMVxtCHYwG6PM_oG67hjw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cahexsgl4tbm-mh+-cm7ytbivmllgrpmvxtchywg6pm_og67...@mail.gmail.com> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://www.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/CAHExSGKbVKuEkaT1J-RW33uXxZ5B5uQ75y0agTXZE%2ByEstV%2BgQ%40mail.gmail.com.
