Storage Foundation migration

[hcldan]

I'm not sure where to put this. I've been following Storage Foundation project for a while, as well as Native File System.
I have seen talk about convergence, and I agree that this would be a good thing. It seems Google has been flailing around in attempts to bring file system support to browsers, and some consolidation and solidity in these efforts is welcome.

I would like to know how the process of deprecating the other APIs (those in or out of origin-trials) will be done.
Can you please be more transparent about direction? I understand that you may still be working out what the direction will be, but it's hard for a company to see what's going on right now and know what horse to bet on.

[fivedots]

Hey Dan,

Our current focus is on Access Handles as the next iteration (and replacement) of Storage Foundation. While there might be some extensions to the Storage Foundation origin trial (currently running until 1 week before Chrome 96 reaches stable), it is unlikely that that particular surface will be available after the trial expires.

There is a new Origin Trial happening for Sync Access Handles running from Chrome 95 to 98, you can register here if you'd like to try it out. While we are still receiving feedback and can make changes, we generally expect to ship something similar to what is in described in the proposal/exposed in the trial.

I'll add a note on the Storage Foundation explainer to make this clearer. I hope this answers your question!

[hcldan]

@fivedots The Access Handles stuff still relies on async stuff, right?.... this is a significant departure from the SF api, and is a huge blocker for the current development we've been doing with storage foundation.

[hcldan]

This thrashing of apis and lack of communication is costing us a pretty significant amount of time and resources trying to see where google is going and what they will eventually support....

[tomayac]

@hcldan, I have documented the migration steps taken so far in the File System Access article and have also added an aside to the storage foundation article.

[hcldan]

@tomayac Thank you for adding these notes, one major area of concern is that it seems a short-cut was taken to reduce the synchronous api access, access that used to be available from StorageFoundation apis. We have already started working and planning for using these apis in workers from WASM code.

The current WASM FS implementation is not performant enough and has very undesirable consequences for large files.
We saw StorageFoundation sync apis in the workers as a solution to this, but now there will be no way to synchronously do a file operation from a sync JS callout. This is a huge breakage for us, I urge you to address this issue in the migration (by providing sync parity with async on the api in workers(#332), or by continuing support for StorageFoundation as an alternative). I would prefer the former.