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

Name may be misleading #38

Closed
domenic opened this Issue Oct 9, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@domenic
Copy link
Collaborator

domenic commented Oct 9, 2018

Someone brought up that the name "async local storage" may imply that this was an async way to access the same data source as localStorage. But that's not true; they're separate. Maybe there's a better name.

Feel free to Bikeshed here!

@janvarga

This comment has been minimized.

Copy link

janvarga commented Oct 10, 2018

Yes, one would think that async local storage is the same thing as existing local storage except it provides async access to the storage, but as you pointed out, that's not the case. It uses IndexedDB as a backing store and AFAIK this store won't be replaceable.
Actually, this new API could be merged into IndexedDB at some point in future (once IndexedDB gets promises, etc.).

@domenic

This comment has been minimized.

Copy link
Collaborator

domenic commented Oct 21, 2018

At this point my favored names are in the space of "key value". E.g. "key-value-store" or "kvdb" or...

This would impact the spec name, and the built-in module name that it's imported by. I think the export names (storage for the default storage area, and StorageArea for the class) are solid.

@domenic

This comment has been minimized.

Copy link
Collaborator

domenic commented Oct 26, 2018

A fan-favorite from one dinner crowd at TPAC was "convenien(t|ce) stor(e|age)".

@developit

This comment has been minimized.

Copy link

developit commented Dec 6, 2018

Suggestions from our meeting:

  • key-value-storage (KeyValueStorage)
  • key-value-store (KeyValueStore)
  • kvstore / kv-store (KVStore)
  • kvstorage / kv-storage (KVStorage)
@asutherland

This comment has been minimized.

Copy link

asutherland commented Dec 7, 2018

Are there concerns about convenience-store name being too quirky/cute/clever? While all of the key-value-store variants describe what the spec would do very aptly, they also squat on existing terminology. I worry any time I said the phrase "key value store" in the future in the context of the browser I'd need to then explicitly describe whether I'm talking about the spec/API or the concept of a key value store, which somewhat defeats the point of a very accurate name.

For example, an existing problem for us in Gecko is that we have our "SessionStore" and "sessionStorage" which are related but also different. I don't relish the prospect of adding an API that increases the number of times I have to go through a "Who's on First" routine...

@domenic

This comment has been minimized.

Copy link
Collaborator

domenic commented Jan 2, 2019

It's a bit cute; I also worry about it being hard to remember, especially convenient vs. convenience. But I'm not really against it...

Maybe "kvstore" as a term of art would help avoid the problem you describe? As opposed to the more generic "key-value-store".

Either way, I'd like to make a decision at some point in the next couple of weeks. Maybe a bikeshedding video call would give us a sense of closure...

@asutherland

This comment has been minimized.

Copy link

asutherland commented Jan 3, 2019

My heart breaks at all of the wordplay that might be left un-played if we don't go with Convenient/Convenience storage, but I agree on the ambiguity between which of the suffixes is correct and the resulting potential for confusion.

KVStorage seems most workable to me of the options from above. I think "store" is more of an abstract concept and we already have localStorage and sessionStorage and the spec exposes "storage" and "StorageArea", so "Storage" is the right suffix. KV is obviously a common abbreviation for "key value", but in general discussion I'd expect English speakers to say "key value" with even odds, especially if they avoid acronyms out of habit. Plus the the google results for "kv storage" (17.3k) are an order of magnitude fewer than "kv store" (144k), suggesting that we can carve out a space there without too much trouble.

If that works for y'all, that works for me. I'm happy to join a call but I don't think I have any real opinion other than maximizing our distance from "key-value store" and the original problem of confusion about whether this is backed by the same storage as localStorage.

@domenic domenic closed this in 7057d3d Jan 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment