search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
670 stars 66 forks source link

Namespace for methods currently added to Window / WindowOrWorkerGlobalScope? #210

Closed pwnall closed 4 years ago

pwnall commented 4 years ago

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.

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mkruisselbrink commented 4 years ago

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

mkruisselbrink commented 4 years ago

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.