Namespace for methods currently added to Window / WindowOrWorkerGlobalScope?

[pwnall]

The spec currently adds three methods to Window (showOpenFilePicker, showSaveFilePicker, showDirectoryPicker) and one method to WindowOrWorkerGlobalScope (getOriginPrivateDirectory).

By contrast, other modern storage APIs have a single entry point.

• The Cache storage API has WindowOrWorkerGlobalScope.caches
• IndexedDB has WindowOrWorkerGlobalScope.indexedDB.

While I'll admit this is not a "regular" storage API (it doesn't only expose access to origin-scoped isolated storage, and its semantics depend on the underlying operating system and file system) I think it would still be nice if we hanged all methods off of a single entry point. WDYT?

[mkruisselbrink]

I don't feel strongly either way. It does seem like getOriginPrivateDirectory is a sufficiently different API from the picker ones that I'm not convinced it makes sense to group those together. Also in workers that is currently the only exposed method. It seems a bit weird to have a namespace for a single method.

Also note that tag guidance seems to argue against the current form of the indexedDB/caches singletons. These days this should at least be a a webidl namespace instead (https://w3ctag.github.io/design-principles/#example-09c8f087). Although I'm not sure what modern APIs have actually taken that advice...

[mkruisselbrink]

So yeah, I guess the option then would be wrap everything in a namespace FileSystem, or leave as is. Perhaps the namespace one would indeed be nicer...

[mkruisselbrink]

although blink bindings don't currently support webidl namespaces; but they can still sort of be simulated by classes with no constructor and only static methods... Which wouldn't be exactly what webidl namespaces are like, but hopefully close enough that we could later change without breaking any code...

[inexorabletash]

Can we call this out on the TAG design review request?

[mkruisselbrink]

Yes, it's on my list, will do asap.

[mkruisselbrink]

After talking to some people, I think I'm leaning towards leaving the various file picker methods alone as free-standing methods on the global, but moving (and renaming) getOriginPrivateDirectory to StorageManager.
There seems little chance for conflict with these names, and as such namespacing doesn't seem to buy us much.