Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify "origin private file system"-ness on a FileSystemHandle #110

Merged
merged 2 commits into from
Jun 14, 2023

Conversation

a-sully
Copy link
Collaborator

@a-sully a-sully commented Apr 6, 2023

Fixes #103
Related to #92 and #109

Gives a FileSystemHandle an "is in an origin private file system" predicate which checks for the empty string in its path


Preview | Diff

@a-sully a-sully requested a review from annevk April 6, 2023 20:31
index.bs Outdated
Comment on lines 561 to 623
1. Let |isInOriginPrivateFileSystem| be whether
[=this=] [=FileSystemHandle/is in an origin private file system=].
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively we could specify "origin private file system"-ness on the file system locator so that it can be checked in parallel, but that seemed less easy to understand

index.bs Outdated
Comment on lines 571 to 572
1. If |isInOriginPrivateFileSystem| is true, [=reject=] |result|
with an "{{InvalidStateError}}" {{DOMException}} and abort.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you worry, #95 will get rid of this in-parallel promise rejection :)

A {{FileSystemHandle}}
<dfn for=FileSystemHandle export>is in an origin private file system</dfn>
if the first [=list/item=] of its [=FileSystemHandle/locator=]'s
[=file system locator/path=] is the empty string.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option here is to define "the root directory of the origin private file system" and check whether the handle "resolves" to that, but that doesn't set us up well for a multi-OPFS future (#92)

Eventually it would be nice to use Storage Buckets here, but I think this is the best we can do for now

Copy link
Collaborator Author

@a-sully a-sully Apr 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just kidding, I just realized that I've been confusing the incubating Storage Buckets API with the already-specified storage bucket concept.

We could give a "file system root" the option to be/have a "storage bucket" (or bottle?), but there's currently no way to get a bucket from the current environment AFAICT? Sorry, I'm not as familiar with how this model is intended to work and I don't have all the context for the issues listed here https://wicg.github.io/storage-buckets/#storage-bucket-getdirectory @evanstade @ayuishii

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OPFS is a storage endpoint and there's one storage bottle inside a storage bucket for each storage endpoint. (The endpoint is like a class, whereas the bottle is an instance of that class.) A storage shelf equates to a storage partition defined by a StorageKey. So a shelf contains buckets which contains bottles.

The issue mentioned in the storage buckets spec is that we need a version of this algorithm which works for any bucket. You'll notice if you drill down into "obtain a local storage bottle map" that it currently assumes the "default" bucket. This just means passing an additional parameter.

We do not currently have a way to go from bottle to bucket for any storage endpoint.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification @estade. I filed #112 to track making getDirectory() work for non-default buckets. Addressing whatwg/storage#2 seems like a prerequisite for adding another parameter to "obtain a local storage bottle map"?

We do not currently have a way to go from bottle to bucket for any storage endpoint.

We just need some way to tie a FileSystemHandle to its root (i.e. two files of the same "file system path" must be considered different if they're from different buckets). There's one OPFS instance per storage bucket, though since there's also only one "fileSystem" bottle per bucket, then using the bottle would also work... though currently, it seems like it's only possible to get a "storage bottle map" and not the storage bottle itself. It seems a bit clumsy to associate a "storage bottle map" with each "file system locator"

Which raises the question of... why don't we just point to the directory entry at map["root"] directly? That would essentially make every "file system locator" a relative path, which on one hand could improve the hand-waviness of the recently-added "locate an entry" and "get the locator" methods, but on the other hand re-raises some of the questions of #59 (i.e. what happens if a root is deleted or moved? #9 (comment))

So, for now at least, I'd prefer to keep "file system locators" absolute and find a way to point to a bottle/bucket :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's any reason not to have a way to retrieve a bottle. We do have ways to get a bucket, but they're currently specified here instead of in the storage spec.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we define OPFS in terms of https://storage.spec.whatwg.org/#obtain-a-local-storage-bottle-map you could make this rely less on magic. But that's a more substantial overhaul.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack. I'll leave this PR as just specifying OPFS-ness on a FileSystemHandle, then we can leave better defining the OPFS itself (in terms of the Storage spec) to a follow-up

index.bs Outdated Show resolved Hide resolved
A {{FileSystemHandle}}
<dfn for=FileSystemHandle export>is in an origin private file system</dfn>
if the first [=list/item=] of its [=FileSystemHandle/locator=]'s
[=file system locator/path=] is the empty string.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we define OPFS in terms of https://storage.spec.whatwg.org/#obtain-a-local-storage-bottle-map you could make this rely less on magic. But that's a more substantial overhaul.

Fixes 103

Gives a FileSystemHandle an "is in an origin private file system"
predicate which checks for the empty string in its path
index.bs Outdated Show resolved Hide resolved
@a-sully a-sully merged commit b2644f0 into whatwg:main Jun 14, 2023
@a-sully a-sully deleted the fix-103 branch June 14, 2023 23:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Consider specifying "origin private file system"-ness on each "file system locator"
3 participants