The storage spec currently uses "default" as the key in a shelf's bucket map for the implicit/default bucket. This leads to the question of whether navigator.storageBuckets.open('default') ought to open a handle to this bucket. (Or navigator.storage.openBucket, see #17 )
On a superficial level, it seems like this reserved string is a bit unfortunate. Developers might accidentally open the default bucket just because "default" is a rather common word and they aren't aware of the special meaning of it. Thus if we are to enable accessing the default bucket, it should probably be available via a special method, such as navigator.storageBuckets.openDefault(). The spec also needs to be updated; we could use a bucket name that's not allowed according to our validation logic, such as "DEFAULT" or "default".
Behaviorally, I think being able to open (or delete, etc) the default bucket could lead to some surprises, like deleting storage bottles that are not actually exposed via the buckets API (such as WebSQL or ServiceWorkers).
It's not clear what use case it would address. #5 asks about migration, but I think to fully support migration we actually need to be able to move data between buckets, not just access the handle to the default bucket.
I suggest starting by making it explicitly impossible and revisit if there is a strong use case.
The default bucket should not be accessible, definitely not in v1.
"default" should not be a reserved string. This can be accomplished by prefixing other buckets or organizing things differently in the Storage Standard. No strong opinions there, whatever is most elegant I suppose.
The storage spec currently uses "default" as the key in a shelf's bucket map for the implicit/default bucket. This leads to the question of whether
navigator.storageBuckets.open('default')
ought to open a handle to this bucket. (Ornavigator.storage.openBucket
, see #17 )navigator.storageBuckets.openDefault()
. The spec also needs to be updated; we could use a bucket name that's not allowed according to our validation logic, such as "DEFAULT" or "default".I suggest starting by making it explicitly impossible and revisit if there is a strong use case.
@asutherland @annevk