jimmywarting
commented
1 year ago Yeah, I understand, no need to worry. There were no comments. You already know my stance on using TS versus js+jsdoc. Also, you removed some things that shouldn't have been removed, like funding and .vscode. There wasn't any issue that required solving, and the use of "Customize" in your PR title, "Use @jcbhmr template," gave it away.
splintering out the FS spec part of this polyfill into its own sort of isolated thing that's only the FS classes without any of the adapters
The idea of separating the FS spec part of this polyfill into its own isolated component, containing only the FS classes without any adapters, has been mentioned before. It has caught my attention, as it might be something people would like to have—a separate place for all the adapters.
Particularly to implement the SyncAccessHandle and other stuff thats not yet in this project
I have given this some toughs and it's challenging to ship any kind of polyfill for these features within browsers. The only feasible way I see is by using Atomic.wait, but that requires SharedArrayBuffer and can only work inside worker threads, not the main thread. Similarly, SyncAccessHandle also only works in worker threads. The only obstacle then is enabling SharedArrayBuffer with specific response headers.
In NodeJS and Deno, this could be much easier since SharedArrayBuffer + Atomic is available in all threads. The package await-sync on npm can certainly help with the synchronization problem. Additionally, since any adapter could be cloud-based (such as Google Drive, Dropbox, OneDrive, etc.), they would also need to communicate with REST APIs in a synchronous manner.
Perhaps the simplest solution would be to develop the adapters in asynchronous mode only, and then the file-system-adapter would handle making all calls synchronous using await-sync. in the SyncAccessHandle so that you don't have to write one async and another that is sync
Sorryu I opened this against the wrong repo! 😬 🤦♂️
Complete rookie mistake. I was meant to open this against my fork in a completely different organization to trim back and just focus on implementing the https://fs.spec.whatwg.org/ stuff.
My bad! I completely didn't realize I targeted 'upstream' when opening this pr 😜
Anyways since I accidentally did this... Hey @jimmywarting I was planning on splintering out the FS spec part of this polyfill into its own sort of isolated thing that's only the FS classes without any of the adapters. I figured this would be an interesting experiment. Particularly to implement the SyncAccessHandle and other stuff thats not yet in this project.