remoteStorage, RemoteStorage, remotestorage, remote storage, Remote Storage, or what? about remotestorage.io

[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
[email protected]:

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//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
[email protected]:

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//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 [email protected]:

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//issues/23#issuecomment-13075395.

[jancborchardt]

Whatever happens, please no dash in the name.

On Mon, Feb 4, 2013 at 2:32 PM, Nick Jennings [email protected]:

good points

On Mon, Feb 4, 2013 at 1:51 PM, Sebastian Kippe [email protected]:

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//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
[email protected]:

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//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 <
[email protected]> 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 [email protected]:

On Tue, Feb 5, 2013 at 12:09 PM, Jan-Christoph Borchardt <
[email protected]> 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//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 <
[email protected]> 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//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 [email protected]:

... 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//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 remotestorage/remotestorage.js#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 [email protected]:

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#224remotestorage/remotestorage.js#224
.

—
Reply to this email directly or view it on GitHubhttps://github.com//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 [email protected]:

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

—
Reply to this email directly or view it on GitHubhttps://github.com//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 [email protected]:

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 [email protected]:

@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//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 <
[email protected]> wrote:

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

On Thu, Feb 7, 2013 at 5:43 PM, Nick Jennings [email protected]:

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 [email protected]:

@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//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 [email protected]:

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.

[michielbdejong]

so then i would call the npm package remotestorage-client to emphasize it's a (server-side) client, which is the unexpected aspect there. emphasizing that it is written in javascript by adding 'js' to an npm module is futile.

[jancborchardt]

Calling the package anything else than »remotestorage« just seems like we
didn’t get that name. Since remotestorage.js is the way to add
remotestorage support to your app, it’s like »just add remotestorage«.

Would there ever be a »remotestorage« npm package? If so, what would it be?
And yeah, the ».js« is just superfluous.

On Thu, Feb 7, 2013 at 7:36 PM, Michiel@unhosted
[email protected]:

so then i would call the npm package remotestorage-client to emphasize
it's a (server-side) client, which is the unexpected aspect there.
emphasizing that it is written in javascript by adding 'js' to an npm
module is futile.

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

[raucao]

Since remotestorage.js is the way to add remotestorage support to your app, it’s like »just add remotestorage«.

You might add remotestorage to your server as well. And node.js is used more for server-side stuff than client-side libs. It'd be clear with Bower or Component that it's a client-side lib, but not for an npm module.

[xMartin]

Thanks for waiting :) I believe things like that need some time and in a way it is rocket science. Naming shit is hard. It is important to us because a name is the first thing people will see of our beloved product that we all put so much effort and passion in. Also we don't want to make ourselves look like fools not sticking to the conventions or even rules about names in all these environments we are advancing. And the worst: there's personal taste and current trends.

I thought about this for some time and then went to the IRC channel to get some inspiration. It helped. So here is my proposal:

It is one word. No space. We write it like so "remoteStorage" because a) we like it, b) we can, c) it is a reference to localStorage (although this may not be technically correct for all times this is how it started and it's ok), d) it looks good and the capital S makes it easy to read. We write it like that everywhere except a) we can only use lower case (it's "remotestorage" then), b) the spec uses lower case but this is deprecated[1], c) the logo is all upper case but this is deprecated[2].

No-one keeps you from using the words "remote" and "storage" when explaining something, but the project and product are called "remoteStorage". The website has it right already, the widget has to be adjusted.

Now what would that mean in concrete changes:

• I think @skddc has it right with filenames, repos, urls. Change them to lower case.
  • lib file: remotestorage.js
  • repo name remotestorage.js
  • github orga: remotestorage
• The JavaScript global object can stay as it is. We like it.
• For npm I'd go for "remotestorage" just because. .js feels silly here and I buy @jancborchardt's arguments about being the remoteStorage lib although it's true that it's not clear that it's a client.

This is my proposal. As you seem to have been waiting for me I ask everybody being active so far in this discussion to give a final opinion/feedback. If we basically agree we can then open new issues for each topic (be it doing actual changes or discussing further).

[1] If there will ever be a chance, rename "remotestorage" in the spec to "remoteStorage". Otherwise we will live with it.

[2] Hold on! I'm not saying we're changing the logo! The logo is great! And it's all upper case so it's not wrong. I'm just saying if we make a major redesign it would be good to reflect the spelling "remoteStorage".

[michielbdejong]

@xMartin wrote:

I think @skddc has it right with filenames, repos, urls. Change them to lower case.

ok, i just checked how jQuery does it, and they also do this, so makes sense. anyway, we now have three proposals:

• "lower": everything lower-case always everywhere
• "mixed": keep the DOM object and the library name camel-case
• "names-vs-urls": use camel-case in names (the DOM object + referring to the library, or the spec, in text), but use lower-case in URLs and filenames.

in all cases the current logo is all-caps and we don't worry too much about that, because it's a great logo.

i'm ok with names-vs-urls, especially since i saw that this is also exactly how jQuery do it (who have the same problem and obviously have some power as a precedent). if this is the option we choose, then we can easily change this in the remotestorage-01 spec, which comes out in June. it actually feels more consistent than the "mixed" option, i think

[jancborchardt]

I fully sign @xMartin’s post. If that’s what you mean with »names-vs-urls«, @michielbdejong, then that would be the proposal of choice, although I think Martin’s post is more of a conclusion of the discussion after having talked to everyone, rather than a third proposal.

So does anyone have objections to what Martin said above? @nilclass @skddc @silverbucket

[silverbucket]

all good for me!

On Sat, Feb 9, 2013 at 6:19 PM, Jan-Christoph Borchardt <
[email protected]> wrote:

I fully sign @xMartin https://github.com/xMartin’s post. If that’s what
you mean with »names-vs-urls«, @michielbdejonghttps://github.com/michielbdejong,
then that would be the proposal of choice, although I think Martin’s post
is more of a conclusion of the discussion after having talked to everyone,
rather than a third proposal.

So does anyone have objections to what Martin said above? @nilclasshttps://github.com/nilclass
@skddc https://github.com/skddc @silverbuckethttps://github.com/silverbucket

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

[michielbdejong]

cool! as it looks like there are no objections to @xMartin's proposal, i updated this in remotestorage/spec@4e907b5 and unhosted/website@918ce15

@nilclass do you want to conduct the honors of renaming the org, the repo, and the names of the (built) files?

[xMartin]

As I said I'd prefer to have separate issues for the actions to take so we can write down in detail what should be done.

Additionally, also as I said, I'd like to wait until everybody that took part in the discussion gave a feedback.

Renaming things might need some more communication like writing to the list and so on. If we want to be more serious about this project, "getting shit done" is not the only thing that matters. Not annoying users too much would be a thing, for instance.

[michielbdejong]

ok, do it. open issues. write to mailing lists.

[michielbdejong]

As I said I'd prefer to have separate issues for the actions to take so we can write down in detail
what should be done.

Done, see remotestorage/remotestorage.js#280

Additionally, also as I said, I'd like to wait until everybody that took part in the discussion gave a feedback.

Done, see current ticket.

Renaming things might need some more communication like writing to the list and so on.

Done, see https://groups.google.com/forum/#!topic/unhosted/vacqrNYSHN8

Thank you all for your patience! :)