TPAC 2022 breakout session agenda

[a-sully]

I've requested time for a breakout session about this API at TPAC (date/time TBA - will update when available). I'd like to use this issue to gather agenda items/topics people would like to talk about

Possible agenda items:

• Alignment on SyncAccessHandle implementation and standardization
  • Supporting multiple writers #34
  • Making all methods sync #7
  • Other features?
• Gauging interest in an async alternative to SyncAccessHandle

Possible agenda items which relate to the non-OPFS portion of the API (tracked in WICG/file-system-access):

• File System Change Events (very early design proposal)
• Supporting access to the file system without an open window
  • Enabling the "background sync" use case
  • Allowing long-running file operations to complete after tab closure

[jesup]

breakout suggestions are open: https://www.w3.org/wiki/TPAC/2022/SessionIdeas

[tlively]

Is it possible for folks not attending TPAC generally to attend this particular session remotely? If so, where can I find more details about how to join?

[a-sully]

Yes, some breakout sessions (including this one) are open to the public, without registration. I assume the schedule will be updated with a video link at some point https://www.w3.org/2022/09/TPAC/schedule.html#wednesday

[a-sully]

Here's the meeting link, including instructions to join remotely: https://www.w3.org/events/meetings/1873ebb8-1207-428c-8f34-f2f4f5b6693f

There's been some shuffling around, so we'll now be meeting at 11:15am PT

The meeting is currently marked as tentative. I'll post updates if anything else changes, but you can also subscribe through that link

[a-sully]

Update: looks like we've also been scheduled for a WICG session from 13:30 to 14:30 on Friday, Sept 16th. There's lots of overlap between the whatwg and WICG specs so it's a bit tricky to talk about these things entirely separately, but I'm thinking we can focus more on the OPFS/Access Handles topics on Wednesday and the topics less relevant to OPFS (change events, background sync, etc) on Friday.

Thoughts?

[szewai]

Hi @a-sully, does the Friday meeting allow remote attendance for TPAC participants?

[a-sully]

Yes! The meeting info is here: https://www.w3.org/events/meetings/02afd4e4-a0e9-48d6-9942-a05ad74175fb

[a-sully]

Thank you to everyone who attended the OPFS-focused breakout session! I was thrilled to see cross-browser support for new features to make SyncAccessHandles even more useful and powerful.

I forgot to ask for an IRC scribe at the start of the meeting, but below are some rough notes @ayuishii kept during the meeting. Please speak up if anything looks incorrect.

Looking forward to the session tomorrow discussing the portion of the File System Access API handling local files (non-OPFS)!

Slides

https://docs.google.com/presentation/d/12jqBnFuTxnTCrmKsUIZJxQyxAsf0yc6Uz7nKF15JzPw/edit?usp=sharing&resourcekey=0-3xJaumMcgsko818iftYRcA

Meeting notes

Topic: Locks

@tlively: Locking files in emscripten, but not across tabs @jesup: spec can define what kind of lock can be taken @a-sully: seems reasonable to also not have a lock option @EisenbergEffect: I was just going to ask if this essentially amounts to C++ code being able to compile ofstream/ifstream code directly to WASM+File System Standard output. a-sully: do we want to introduce byterange file locking into the API or trust the devs tlively: emscripten does not do cross tab coordination, it will need to be at the webplatform layer. @szewai: can’t expect emscripten to be the only implementer. To support multiple readers & writers. Multiple readers might be easier. jesup: would make it hard for developers if don’t give that ability… tlively: would expose platform differences, but doesn’t matter for application uses like myself a-sully: Consensus: exclusive locking, can opt into shared locking, unsafe share at your own risk @nolanlawson: Would that exclude cross origin isolated apps? a-sully: yes tlively: you can’t used shared memory to coordinate between the tabs, it would need to be out of band shared memory @inexorabletash: can use web locks API, provide shared exclusive locks across tabs

Topic: Async alternative to SyncAccessHandles

a-sully: Motivated to change the name. We eventually expect Wasm to handle async code as well. Seems future proof, does any one want it? inexorabletash: Async seems like the right thing for the platform, but need partners. tlively: Sync just seems more appealing to me if given two options. jesup: Can use it from the main thread is the top benefit. a-sully: Opportunity to do streams, different implementation from sync, support service workers, which can't spawn a dedicated worker ?: Is there shim? a-sully: Could have a pollyfill. Operations are async from the perspective of the main thread if it posts operations to a worker jesup: Interested in this direction, would be worth putting together a proposal for this tlively: Main thread access is compelling. No users that I know if that use single thread application, but expect more single threaded users with swap to new file system API. Projecting the future, the use cases seems compelling. a-sully: Consensus: We want this, but not immediate wants

Topic: Naming

jesup: Resolve method is important. Getting the parent of the object we should also figure out. a-sully: OPFS makes sense. Tricky outside of OPFS, unclear of expected behavior. jesup: Sounds like its fine to have 2 different behaviors for OPFS/non-OPFS @morsssss: We should find a better name for Access Handles jesup: FD might make sense (file descriptors)

Topic: Spec/WPT conformance

jesup: Status update from Mozilla. Dom fs enabled flag available tomorrow. Writable file stream and post message support will come soon. Photoshop will work soon. inexorabletash: How is test coverage? jesup: There are bugs in the wpt. A lot of behavior that isn’t in the spec. Have raised issues with them. …: What happens when you do something, remove a handle, and access after. It is not speced. Tests go to the implementation not to the spec. …: Haven’t checked coverage, completion. a-sully: Trying to resolve move() right now jesup: Tricky existing things are when there are test failures, there is a cleanup issue with files being left behind. Fixing them in our tree. Should come upstream soon. jesup: Current Mozilla implementation, if you move a file, all the handles move too bc we have stable IDs assigned to the object. This will be a different implementation behavior which should be explicit in the spec. Webkit has the same feeling as Mozilla. Inconsistencies in implementation and specified in the spec. a-sully: please open github issues for anything

[jesup]

the flag in Firefox is "dom.fs.enabled" in about:config

[a-sully]

Thank you all for attending! Here are the slides from the WICG (non-OPFS) session