Re: [w3ctag/design-reviews] Sync Methods for FileSystemSyncAccessHandle in File System Access API (Issue #772)

There's a lot of great discussion by WASM developers on https://github.com/whatwg/fs/issues/7 which illustrate the need for this change. [This comment](https://github.com/whatwg/fs/issues/7#issuecomment-1201811600) (sampled below) provides a pretty good summary of my thoughts:

> From my perspective as a Chromium engineer, we are currently focused on making SyncAccessHandles as performant as possible to support C(++) applications being ported to the web via WASM, but we are very interested to hear developer feedback about whether an asynchronous alternative to SyncAccessHandles is worth pursuing. One could imagine an async alternative could be more webby: available from Window contexts etc, using a streams-based interface with built-in queueing, etc. To this point we haven't seen much developer demand for this async alternative. If you have compelling use cases for an async alternative, we'd love to hear your feedback :)

> Okay, so here's the reality of the current landscape:
> - asynchronous WASM is not performant enough to support the most powerful web applications (for now!)
> - applications porting C(++) code to WASM expect a synchronous, Posix-like file API
> - a split sync/async interface is a no-win compromise

> I'm excitedly following the developments to improve async support in WASM. My hope is that this will allow an async alternative to SyncAccessHandles to have comparable performance characteristics, at which point any web developer looking for fast storage will have no reason to choose the more restrictive SyncAccessHandles.

> That being said, it's also unclear to me whether C(++) applications being ported to WASM would be able to use or benefit from this async alternative as easily as SyncAccessHandles. There may always be a need for a synchronous file API to support porting these applications to the web.

> The current split interface is the worst of both worlds. We'll never be able to expose SyncAccessHandles to anything other than DedicatedWorkers due to the existence of sync methods. However, the split sync/async interface forces the application to write effectively sync code anyways, since you can't queue operations due to the sync methods. The result is a significantly slower and more complicated interface than if all the methods were sync. I'd like to see SyncAccessHandles be the MOST useful for WASM-compiled applications, while keeping an ear out for WASM ecosystem async support + developer demand for an async alternative.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/772#issuecomment-1294041695
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/772/1294041695@github.com>