renaming to remotestorage-django about django-remotestorage

[mk-fg]

First, django packages are usually named django-something, so I think django-remotestorage should be better.

Renaming package is generally A Bad Idea (forcing users to do manual configuration changes, links update, uninstall of previous packages, manual cleanup, etc).
Ideally, some horribly complicated migration process should be described or implemented.
It's basically an act of agression against existing users, but I don't think it has many of these, so probably not really bad.

More importantly, package implements unhosted storage, so the name isn't completely off the mark.
Description and metadata make it fairly clear that implementation supports remotestorage, so I'm not convinced if it's a real problem.

Current plan is to keep support for remotestorage 0.6 and add support for remotestorage 0.7 (after it's release), and I wanted to rename it along with 0.7 support, but then I don't see why not expose the same stored data through other interfaces.
I can't think of any valid reason to do that however, since remotestorage already provides public http access, if necessary, and pretty much anything can probably work with that.

One option that I've actually mentioned and considered is to leave django-unhosted as-is with only remoteStorage-0.6 support and fork django-remotestorage for 0.6+0.7+..., but now I don't think it's a good idea.

Overall I think rename should still be done (soon), just wanted to mention that it's not completely uncontroversal and write down the whys as I see these.

[mk-fg]

Following "the sooner the better" approach, just renamed the app, repo, pulled down django-unhosted from pypi and added django-remotestorage there.

6b6d5cd and f95f62c should illustrate the outlined migration problems nicely.

[jancborchardt]

Just as info @mk-fg: There is no such thing as an »unhosted storage«. There are unhosted web apps and remotestorage. :)

[mk-fg]

But there IS some storage involved, so maybe it's unhosted-web-app-friendly storage, which may include any R/W storage with CORS, for example.
My point is that such concept implicitly exists anyway, so maybe it should be given an explicit name (if only for ease-of-use in conversations)?

EDIT: Probably a topic for the list, might as well post it there...

[jancborchardt]

Yeah, it’s called remotestorage. See http://remotestorage.io and the mailing list post at http://librelist.com/browser//remotestorage/2012/9/12/remotestorage-separation-from-unhosted/

[mk-fg]

That is, unhosted web apps can work without remotestorage. They can
just use localStorage, or they can use Dropbox, Google Drive, iCloud
or any other storage standard. Although remotestorage for now is the
recommended open standard because it is standardized, interoperable
and can be deployed by anyone.

So unhosted webapp is NOT only remotestorage-webapp.
I mean the name for "remotestorage, localStorage, Dropbox, Google Drive, iCloud or any other storage standard" "unhosted-web-app-friendly storage, which may include any R/W storage with CORS, for example".
(note the "any R/W storage" part in message above)

Current plan is to keep support for remotestorage 0.6 and add support for
remotestorage 0.7 (after it's release), and I wanted to rename it along with 0.7
support, but then I don't see why not expose the same stored data through other
interfaces.  I can't think of any valid reason to do that however, since
remotestorage already provides public http access, if necessary, and pretty much
anything can probably work with that.

What I wanted is to give a name to that "Dropbox, Google Drive, iCloud or any other storage standard" thing, which might be reasonable to add to (ex-)django-unhosted in the future, so any competing-standard-using-unhosted-webapp (non-remotestorage!) might also work with the same data, which might initially be uploaded (or "also used with") remotestorage.

Sure, maybe "unhosted storage" is a confusing name for such thing, and maybe such name is indeed unnecessary, but from your last reply, I think you misunderstood me and wanted to clarify what I meant above.

[jancborchardt]

Ok, then the short description might be confusing: »remoteStorage server implementation as a django app«

So – is it something you would put in your app to enable people to use their remotestorage – or is it a server which you can use to store your data and use with unhosted apps?

It sounds like the latter from the short description, but like the former from your comments.

[mk-fg]

django-remotestorage is definitely a server-side django app ("django app" == "Small components used to build projects. An app is anything that is installed by placing in settings.INSTALLED_APPS."), so it is a server used to store/serve data from/to unhosted apps.

To be more precise: http://ompldr.org/vZmlhaw/apps_graph.svg
Red things on that graph are what I was calling "unhosted storage" above.

[jancborchardt]

Oh, sorry for not coming back earlier.

Now I understand what you mean, yes. My only concern is that we probably shouldn’t use the term »unhosted storage« but rather name it: Dropbox, Google Drive, remotestorage, etc. – or say web storage or whatever, because remotestorage, Dropbox etc are not only for unhosted web apps.