Closed Jamesernator closed 1 year ago
Would Storage Buckets address this use case? The current implementation only works with IndexedDB, but the eventual plan is to enable it for other storage methods as well.
Would Storage Buckets address this use case? The current implementation only works with IndexedDB, but the eventual plan is to enable it for other storage methods as well.
Plausibly, though from reading the explainer it seems that deletion is still in general lazy, i.e. when disk storage becomes high. Like if I do the following:
class Archive {
static async create() {
const bucketId = crypto.randomUUID();
const bucket = navigator.storageBuckets.open(this.#bucketId, { persistent: false });
return new Archive(bucketId, bucket);
}
constructor(bucketId, bucket) {
this.#bucketId = bucketId;
this.#bucket = bucket;
}
addFile(fileName, blobSource) {
const rootDir = await this.#bucket.getDirectory();
const filesDir = await rootDir.getDirectoryHandle("files", { create: true });
// add file to files dir
}
async encode() {
const dir = await this.#bucket.getDirectory();
const archive = await dir.getFileHandle("archive.ext", { create: true });
// encode things to the archive
return archive;
}
async dispose() {
await navigator.storageBuckets.delete(this.#bucketId);
}
}
and create an archive, and close the page before .dispose()
is called, then files within the storage bucket will still be on disk until disk usage is high. Thus it'd be wasting disk space for something that will never be accessed again.
From the issues on storage buckets it seems like session buckets is probably the most appropriate place for this, so I'll close this issue.
NOTE: This issue is not a request for access to the user's tempory directory/files.
So the file system APIs are fairly convenient for writing files, however at present all files/directories are either persistent or not regardless of need.
For use cases like reading/writing large archives, it would be desirable to be able to have temporary files/directories that can be written like other files but are automatically collected when no references remain.
Strawman API
Alternatives considered
OPFS +
beforeunload
- This is this only available on the main thread which makes it inconvenient for use in workersOPFS +
FinalizationRegistry
on wrapper objects - Finalization of objects is not guaranteed to occur at all so can't be reliably used to dispose of file-system-handlesBoth approaches don't work either if
.terminate()
is called on a worker as there would be no opportunity for the worker to perform cleanup.