remoteStorage, RemoteStorage, remotestorage, remote storage, Remote Storage, or what?

[raucao]

I just saw that the latest IETF spec breaks with the old W3C wiki one in regards to the precise naming and uses "remotestorage". As this is an important question for presentation and usage, and it seems to have silently changed and, more importantly, be used differently by different people and in different contexts, we should have a proper discussion and decisions on how exactly the term is written and used in all contexts.

I think "remotestorage" looks very wrong in almost all situations, but especially in ones, where you want to refer to the actual storage instead of the protocol or library (e.g. "connect your storage". I vote for that case to just use "remote storage". I don't think it will be an issue with other products, because you'd then normally use the product name (or other open standard name) instead of this seemingly generic term.

In regards to the protocol and libraries, it seems to me that it makes more sense to use the lower camelCase version, as this not only reflects the localStorage standard, but also divides the word visibly. Which looks much less wrong to my eyes, because in English you usually don't have composed words without separative characters.

Like any word, it should always be possible to use it in all caps for logos etc. (and in the current logo it is set in 2 lines, also making it "REMOTE STORAGE" by the way).

[raucao]

2 more things:

1. Ironically, this organization is called "RemoteStorage", while the Twitter account has the username "remotestorage_" and real name "remote storage".
2. For URLs and things like usernames or orgname slugs, I think all lowercase and one word is the one valid use case for that spelling and should be used and unified throughout the Internets.

[michielbdejong]

the reason it changed in the link relation (the 'rel' in the webfinger link) is that link relations apparently can only contain lower case. Same for the name of the specification i think (draft-dejong-remotestorage-00.txt has to be all lowercase). as for the "name" of the protocol, i think 'remotestorage' is nice when you say "compliant with the remotestorage protocol". But i agree that when talking about a server it makes more sense to say "connect your remote storage", otherwise it looks wrong. can't we keep remotestorage as the name of the spec (bit hard to change now, anyway), and then just say "your remote storage" when referring to a server instance, so that it doesn't look weird?

[raucao]

As I said, URLs, filenames, and any other slugs should always use all-lowercase spelling anyway (due to having it unified, because a lot of systems require that anyway and because you can't count on case-sensitivity there).

That doesn't have anything to do with real names of specs, libraries, etc. though, or does it?

[raucao]

For reference: http://www.w3.org/TR/webstorage/ for a spec named "Web Storage", including a "localStorage attribute".

[jancborchardt]

We talked about this at Hacker Beach, also with @nilclass, @xMartin & @silverbucket.

For developers (in code etc), it should be »remotestorage« for sure, phasing out the remoteStorage camel casing also because the localStorage connection doesn’t really hold up anymore.

For users now, in the widget it currently also is »remotestorage«. The reason I used »remote storage« anywhere is to also get that more general keyword to point to remotestorage.

TL;DR: »remoteStorage« and »RemoteStorage« should go completely because of crappy capitalizing, »remotestorage« is for devs, and »remote storage«/»Remote Storage« might be good for general language.

[michielbdejong]

just so that we're clear on this, Jan's proposal would change code like:

    var songs = remoteStorage.music.getListing();

to

    var songs = remotestorage.music.getListing();

and what we could then do is leave a remoteStorage object present in the DOM, just with a deprecation warning. and then we should also at same time just rename the org and the repo and just get it over with.

[raucao]

So, the arguments against camelCase for devs are:

• "because the localStorage connection doesn’t really hold up anymore"
• "because of crappy capitalizing"

Sorry, but those are not very convincing. For one, the connection still holds up pretty well, because it's a storage API made for client-side web apps, but instead of local it's remote, and furthermore the "crappy capitalizing" makes it much easier to read anywhere, which is what it's for, just like spaces, dashes and other separators.

It's nice that you talked about it somewhere, but you never talked about it with the guy who raised the issue, and for now you didn't give a single reason that is based on an objective, neutral argument. Please do so, because while I agree for the user side, I still don't see how remotestorage is better than remoteStorage for developers. Thanks.

[silverbucket]

During our impromptu talk, I also did not buy into the reasons given. I'm open to the idea of a name change, but don't think it's terribly necessary

• what I really don't like, though, is the careless switching of the way it's written based on mood. We should have a standard approach to the naming and stick with it. I have remotestorage and remoteStorage in my code directories, and I don't like having to tab-complete twice! :)

On Sun, Feb 3, 2013 at 11:26 AM, Sebastian Kippe notifications@github.comwrote:

So, the arguments against camelCase for devs are:

• "because the localStorage connection doesn’t really hold up anymore"
• "because of crappy capitalizing"

Sorry, but those are not very convincing. For one, the connection still holds up pretty well, because it's a storage API made for client-side web apps, but instead of local it's remote, and furthermore the "crappy capitalizing" makes it much easier to read anywhere, which is what it's for, just like spaces, dashes and other separators.

It's nice that you talked about it somewhere, but you never talked about it with the guy who raised the issue, and for now you didn't give a single reason that is based on an objective, neutral argument. Please do so, because while I agree for the user side, I still don't see how remotestorage is better than remoteStorage for developers. Thanks.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13044997.

[michielbdejong]

yes, i think obviously the sole reason to change it from remoteStorage to remotestorage in the code (i.e., the DOM object as well as the script filename) would be for consistency with how we want to spell it in the user-facing communication.

[silverbucket]

I don't know what we should do about end-users or user-facing communication

• that being people who are not at all interested in the library remoteStorage, but just have a storage provider that they use apps with. Maybe the name of the protocol spec and provider services should be changed? (not just a change in case, or spacing, - which I think has already added confusion - but actually changed). Just a thought - not sure I like the idea but thought it was worth bringing up as a possible solution to the issue.

However, I think the name remoteStorage, from a developer perspective, looks good and really helps to convey an idea of the library to the developer at first glance. I haven't seen any convincing reason why things would be improved, from a developer community standpoint, by having it changed to 'remotestorage'.

It seems like the main issue here is that the library is a developer-centric thing, the storage service is not, so there's a designer vs. programmer conflict going on. :)

On Mon, Feb 4, 2013 at 12:46 AM, Michiel@unhosted notifications@github.comwrote:

yes, i think obviously the sole reason to change it from remoteStorage to remotestorage in the code (i.e., the DOM object as well as the script filename) would be for consistency with how we want to spell it in the user-facing communication.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13058154.

[michielbdejong]

i think the current situation seems to tend that we call the org and the spec (including the link rel and the API defined by the spec) remotestorage[.io], but we call the DOM object and the library remoteStorage[.js]. it's true that end-users will never see the DOM object, nor the library, so if we just define that that is how we do it, then we don't have to change anything except for the github org name. that would mean we programmers can keep our beloved remoteStorage DOM object, and the users and designers don't need to know about it. it wil be our little secret. ;) and saves us the pain of deprecating an existing variable name.

but i also think there is no perfect option here, and we could talk forever without ever fixing the issue, whereas any decision is probably better than no decision.

[nilclass]

+1

We need to figure out how to go about renaming the organization. We need to give everyone a bit of a warning, so people know they need to change their git config.

One more thing to consider is the npm package. It must be all lowercase, so we can use "remotestorage" or "remote-storage" or "remotestoragejs" or "remotestorage-js" or "remote-storage-js". I vote for "remotestorage-js" or "remote-storage", but the others are also ok.

[raucao]

Just 2 comments to the responses so far:

Both GitHub org names and domain names should always be lowercase, no matter how the original name is spelled. That goes for repo names as well. And if there's e.g. a space in the name they represent, it should be separated by a dash. This is because not all systems are even case-sensitive when it comes to URIs, and DNS ignores case in hostnames straight away.

It's also not necessary to have a JS object be the same spelling as something else. It's a pure object name then, and should use JavaScript convention for separating words.

[raucao]

Oh, and another lowecase case. :)

These 2 seem the best to me as well.

[silverbucket]

good points

On Mon, Feb 4, 2013 at 1:51 PM, Sebastian Kippe notifications@github.comwrote:

Oh, and another lowecase case. :)

These 2 seem the best to me as well.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13075395.

[jancborchardt]

Whatever happens, please no dash in the name.

On Mon, Feb 4, 2013 at 2:32 PM, Nick Jennings notifications@github.comwrote:

good points

On Mon, Feb 4, 2013 at 1:51 PM, Sebastian Kippe notifications@github.comwrote:

Oh, and another lowecase case. :)

These 2 seem the best to me as well.

— Reply to this email directly or view it on GitHub< https://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13075395>.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13076889.

[michielbdejong]

ok, this issue is now 2 months old, let's try to help this discussion a bit closer towards its end-game, so we can close this ticket:

If i followed the discussions correctly, then in all cases, by definition, http://remotestorage.io/ and http://remotestoragejs.com/ are all lower-case. Also in all cases, in natural language it would be two words; examples:

Connect your remote storage.
Get a remote storage account at this remote storage provider.

Is that correct so far? Except when talking specifically about the technical protocol, then it would be:

Your API is not remotestorage-compatible.

I think so far we're all on the same page, right? Now where we have to make a choice is whether to make only the protocol name lower case, or also the DOM object. So:

Option: org:          protocol:     link-rel:     library:         DOM-object:   script:          npm-lib:
"lower" remotestorage remotestorage remotestorage remotestorage.js remotestorage remotestorage.js remotestorage-js
"mixed" remotestorage remotestorage remotestorage remoteStorage.js remoteStorage remoteStorage.js remotestorage-js

If this is a correct reflection of what everybody said, then please vote, if not then please add more options to the list, and vote for those. I vote for 'mixed'.

[nilclass]

I'm fine with that, except for the name of the library. I think if we call the npm package "remotestorage-js", so we should call the repository. That should also clean up inconsistencies with repository URLs (i.e. you can browse the repository at github.com/remotestorage/remotestorage.js - because github ignores the case -, but when cloning via git:// protocol that won't work, because it is case sensitive).

[raucao]

In the case of compound words it'd have to be "remote-storage account" and "remote-storage provider" then; otherwise the account and the provider are remote, not the storage. At least it's not apparent that the storage is meant and that that is some kind of special storage type. If we use normal English words, we just have to abide by English grammar rules, otherwise it doesn't make sense. I don't see how anyone could discern our remoteStorage from any other remote storage thing, though. Maybe that's intended, but I'm not sure that it's a good idea.

+1 on mixed, but also with @nilclass's addition of making filenames lowercase.

[jancborchardt]

Can the npm package also just be called »remotestorage.js«, or are only dashes allowed? It seems a bit ridiculous to name it »remotestorage-js« because »dot js« is the whole point of the library.

And maybe also hinting to @xMartin, just call it »remotestorage« without js (although that would probably not be good because storage servers could also be distributed through npm, right?)

On Tue, Feb 5, 2013 at 10:42 AM, Sebastian Kippe notifications@github.comwrote:

In the case of compound words it'd have to be "remote-storage account" and "remote-storage provider" then; otherwise the account and the provider are remote, not the storage. At least it's not apparent that the storage is meant and that that is some kind of special storage type. If we use normal English words, we just have to abite by English grammar, otherwise it doesn't make sense. I don't see how anyone could discern our remoteStorage from any other remote storage thing, though. Maybe that's intended, but I'm not sure that it's a good idea.

+1 on mixed, but also with @nilclass https://github.com/nilclass's addition of making filenames lowercase.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13121665.

[jancborchardt]

And btw, Michiel’s table makes it pretty obvious that mixed case is confusing, as only the library/script and the DOM object would be named camel case.

[silverbucket]

On Tue, Feb 5, 2013 at 12:09 PM, Jan-Christoph Borchardt < notifications@github.com> wrote:

And btw, Michiel’s table makes it pretty obvious that mixed case is confusing, as only the library/script and the DOM object would be named camel case.

If only it were true :) We use this localStorage package for remoteStorage testing at the moment. It clearly shows that you can use camelCase with NPM pacakges. https://npmjs.org/package/localStorage

the github repo: https://github.com/coolaj86/node-localStorage

[jancborchardt]

Huh? I said nothing about camel case not being possible in npm package names.

So while you’re testing, do they allow dots also, so we can name the package remotestorage.js?

On Tue, Feb 5, 2013 at 12:55 PM, Nick Jennings notifications@github.comwrote:

On Tue, Feb 5, 2013 at 12:09 PM, Jan-Christoph Borchardt < notifications@github.com> wrote:

And btw, Michiel’s table makes it pretty obvious that mixed case is confusing, as only the library/script and the DOM object would be named camel case.

If only it were true :) We use this localStorage package for remoteStorage testing at the moment. It clearly shows that you can use camelCase with NPM pacakges. https://npmjs.org/package/localStorage

the github repo: https://github.com/coolaj86/node-localStorage

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13126001.

[silverbucket]

@jancborchardt you said only the DOM and library script would be camelCased, coinciding with @michielbdejong's table which shows the npm name as 'remotestorage-js'. It's incorrect, the package name can be 'remoteStorage' in NPM.

Also I sent this message via email but it seems github issues dropped it, it's why i suggest we don't bother with .js or -js:

Node is JS, so the -js, or .js becomes superfluous. I like the idea of 'remoteStorage' being the npm name. Similar to how Sinon.JS is simply 'sinon' and node-mail is 'mail'.

I think, for servers, they all have specific names, there hopefully wont be a project that names itself remotestorage and is a server. That would be confusing in more ways than just NPM. However, there could always be a 'remotestorage-server' npm package.

[jancborchardt]

I’m fine with that. Summary of my opinions:

• camelCase, like remoteStorage: ok, whatever
• .js, like remotestorage.js: I’d rather not (see Nick’s and Martin’s statements)
• dashes, like remote-storage: no way (we never used that anywhere, also looks like someone else got the »proper« undashed name)

[raucao]

Thanks for announcing the end of a discussion without citing a single objective argument.

[jancborchardt]

@skddc sorry for leaving out the rolling eyes smiley to make it evidently clear that it was a joke, and only refers to my involvement in the discussion.

P.S.: @silverbucket it being possible to use camel case in npm package names doesn’t warrant using it. Rarely any other package (I found none) does it.

[michielbdejong]

i think what @jancborchardt means as that since he said:

camelCase, like remoteStorage: ok, whatever

that he is ok with it if we decide on the "mixed" option, which i think most other people seem to favor. so leaving the DOM object and the library as remoteStorage and remoteStorage.js respectively. so then that's cool, that would settle at least the main discussion point, and can move on to the minor ones:

@skddc's point about natural language: we don't have to be as strict about natural language, because natural language is loosely defined by design. so we can just do that however it fits in the sentence.

the npm package name is also more peripheral, if we can have require('remoteStorage') as @silverbucket says then i +1 that; if not then i would personally vote for probably just require('remotestorage') or maybe require('remotestorage-client') would be nice. i agree that remotestorage-js is a bit weird because an npm package is js by definition.

[jancborchardt]

Yes, I’m ok with the mixed option, and also agree with @michielbdejong’s point about not having to be as strict about natural language uses.

For what it’s worth: dots are possible in npm package names, see smith.io – nevertheless »remotestorage« seems to be the most elegant choice for package name.

[michielbdejong]

Great! let's wait for @xMartin to get a chance to vote, and then we can announce the conclusion and rename the github org

[silverbucket]

On Tue, Feb 5, 2013 at 2:56 PM, Jan-Christoph Borchardt < notifications@github.com> wrote:

Yes, I’m ok with the mixed option, and also agree with @michielbdejonghttps://github.com/michielbdejong’s point about not having to be as strict about natural language uses.

For what it’s worth: dots are possible in npm package names, see smith.io– nevertheless »remotestorage« seems to be the most elegant choice for package name.

You mean remoteStorage right? That's the library name and as long as we don't change the name / switch the case, we should always use it everywhere we can.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13130080.

[raucao]

... except in URIs or filenames due to the problems with case (in)sensitivity!

Regarding changing natural language: yes, it's loosely defined by design, but it's used with conventions, and people don't change their perception of it, just because you yourself think it makes sense that way (and you don't even tell them). As I said, if you use compound words without making it clear that remote and storage are one term, then the remote will be perceived as belonging to whatever comes last by a ton of people.

[silverbucket]

On Tue, Feb 5, 2013 at 4:59 PM, Sebastian Kippe notifications@github.comwrote:

... except in URIs or filenames due to the problems with case (in)sensitivity!

"where we can" :)

Regarding changing natural language: yes, it's loosely defined by design,

but it's used with conventions, and people don't change their perception of it, just because you yourself think it makes sense that way (and you don't even tell them). As I said, if you use compound words without making it clear that remote and storage are one term, then the remote will be perceived as belonging to whatever comes last by a ton of people.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13136183.

[michielbdejong]

ok, so now that we have a rough concensus about this, can someone please rename the org cc @nilclass @xMartin so then the repos will be:

https://github.com/remotestorage/remoteStorage.js https://github.com/remotestorage/remotestorage.io

Looks much nicer! :) and then we can finally close this ticket. \o/

[xMartin]

Can we wait a bit with renaming actions? At least I haven't been following the whole discussion and I wanna do so and make up my mind without pressure. We've had premature decisions like that in the past and that was bad. Or are we in a hurry here?

[michielbdejong]

No, no rush. As i said two days ago:

Great! let's wait for @xMartin to get a chance to vote, and then we can announce the conclusion
and rename the github org

So to recap, the current proposal is:

DOM object: remoteStorage
library: remoteStorage.js
org: remotestorage
spec: remotestorage-00

Take your time, no pressure. :) There is no particular deadline or anything

[nilclass]

Another proposal for the library was remoteStorage-client

Also,

modules: remoteStorage-{module}

[michielbdejong]

yeah, i only mentioned the four 'core' ones

[nilclass]

I think naming of module packages should be consistent with naming of the library (i.e. {library}-{module}). Module naming was also discussed in https://github.com/RemoteStorage/remoteStorage.js/issues/224.

[nilclass]

FYI, I have created https://github.com/RemoteStorage/remoteStorage-locations now, but can still rename it, if this issue yields a different naming pattern.

[silverbucket]

If we go with{library}-{module} would that be remotestorage-client-documents?

On Thu, Feb 7, 2013 at 3:10 PM, Niklas Cathor notifications@github.comwrote:

I think naming of module packages should be consistent with naming of the library (i.e. {library}-{module}). Module naming was also discussed in RemoteStorage/remoteStorage.js#224https://github.com/RemoteStorage/remoteStorage.js/issues/224 .

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13237192.

[nilclass]

@silverbucket possibly

[silverbucket]

I kind of like the idea of remoteStorage-module-{name} ... just to be ultra-uber-clear

On Thu, Feb 7, 2013 at 5:40 PM, Niklas Cathor notifications@github.comwrote:

@silverbucket https://github.com/silverbucket possibly

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244719.

[jancborchardt]

Let’s keep it simple please. remoteStorage-{module} (or lowercase, whatever) suffices.

On Thu, Feb 7, 2013 at 5:43 PM, Nick Jennings notifications@github.comwrote:

I kind of like the idea of remoteStorage-module-{name} ... just to be ultra-uber-clear

On Thu, Feb 7, 2013 at 5:40 PM, Niklas Cathor notifications@github.comwrote:

@silverbucket https://github.com/silverbucket possibly

— Reply to this email directly or view it on GitHub< https://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244719>.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244858.

[michielbdejong]

for the module repo's let's use remoteStorage.module because that is also the name (in the DOM) of the module they introduce. so for instance:

remoteStorage.music

[silverbucket]

could theoretically conflict with project names.

On Thu, Feb 7, 2013 at 5:44 PM, Jan-Christoph Borchardt < notifications@github.com> wrote:

Let’s keep it simple please. remoteStorage-{module} (or lowercase, whatever) suffices.

On Thu, Feb 7, 2013 at 5:43 PM, Nick Jennings notifications@github.comwrote:

I kind of like the idea of remoteStorage-module-{name} ... just to be ultra-uber-clear

On Thu, Feb 7, 2013 at 5:40 PM, Niklas Cathor notifications@github.comwrote:

@silverbucket https://github.com/silverbucket possibly

— Reply to this email directly or view it on GitHub<

https://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244719>.

— Reply to this email directly or view it on GitHub< https://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244858>.

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remotestorage.io/issues/23#issuecomment-13244939.

[nilclass]

:-)

[nilclass]

concerning npm modules and capital characters:

nil@tp:~/src/rs$ npm publish
npm http PUT https://registry.npmjs.org/remoteStorage.js
npm http 403 https://registry.npmjs.org/remoteStorage.js
npm ERR! publish Failed PUT response 403
npm ERR! Error: forbidden New packages must have all-lowercase names: remoteStorage.js

[silverbucket]

On Thu, Feb 7, 2013 at 6:17 PM, Niklas Cathor notifications@github.comwrote:

concerning npm modules and capital characters:

nil@tp:~/src/rs$ npm publish npm http PUT https://registry.npmjs.org/remoteStorage.js npm http 403 https://registry.npmjs.org/remoteStorage.js npm ERR! publish Failed PUT response 403 npm ERR! Error: forbidden New packages must have all-lowercase names: remoteStorage.js

yeah tried earlier today with the same result. I don't know how localStorage got their case. Maybe its a new restriction?

[raucao]

Filenames, URIs, and therefore also repo- and package names should always be lowercase. Reasons already stated twice.