remotestorage separation from unhosted

[Jan-Christoph Borchardt]

We talked a lot about the relationship of unhosted and remotestorage
in the past, and at the Unhost unconference finally with more people
than just Michiel and me. We concluded that since we introduce 2
technical concepts to people which do not necessarily need to be
connected, we should separate them more clearly. While there is lots
of possible overlap and remotestorage was born out of the then
Unhosted project, we should have 2 strong separated brands also to
avoid confusion what is what.

»unhosted« means client-side web apps, written in Javascript, HTML,
CSS (check http://unhosted.org )
»remote storage« means per-user storages which use OAuth, CORS &
get-put-delete (adhering to
http://w3.org/community/unhosted/wiki/RemoteStorage )

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.
And remotestorage can be used by more than just unhosted web apps. We
talked to people of Libre Office and Thunderbird before, and in
presentations have always said that the web apps do not necessarily
need to be client-side only. But unhosted web apps are recommended,
since they are platform-independent, portable and do not track you.

So let’s go! We have a new Github organization at
http://github.com/remotestorage – I already added some people involved
with remotestorage, and the remotestorage.js repository moved there
from unhosted.
Join our IRC channel #remotestorage on freenode.net and the mailing
list is kicked off with this post – join by mailing to
remote...@librelist.com, the archives will be available at
http://librelist.com/browser/remotestorage/
Also follow https://twitter.com/remotestorage_


Freedom from the web’s monopolies!

[Jan-Christoph Borchardt]

So what do we have?

app libraries:
https://github.com/remotestorage/remotestorage.js (Javascript)
https://github.com/lukashed/remoteStorage.py (Python)

remote storages:
https://github.com/owncloud/core (PHP) used by http://owncube.com
https://github.com/fkooman definitely has some, not sure which repo
though ;) used by SURFnet
https://github.com/5apps/liquor-cabinet (Ruby) used by http://5apps.com
https://github.com/pagekite/plugins-pyUnhosted (Python) used by
http://pagekite.net
https://github.com/jcoglan/restore (Node.js)
https://github.com/5apps/express-storage (Node.js) possibly deprecated
https://github.com/mk-fg/django-unhosted (Python)


Do we fork them to the remotestorage Github organization? Or do we ask
the authors if they want to transfer ownership to remotestorage, in
which they can continue to develop them there? Or do we do nothing at
all, just maybe linking to them?

I think asking the authors to transfer ownership is best (except
ownCloud, which is not a dedicated remote storage only). Those which
don’t want to do that we’ll still link, but it’s best to have it under
one umbrella because it’s all about the same standard.

CC’d the authors – please let us know your stance on this.

[Martin Stadler]

We also have http://remotestoragejs.com which is not a good fit for the whole project. We're trying to get remotestorage.org or, if that doesn't work out, remotestorage.io to put up a website for everything around Remote Storage, like

* description of the technology in general (linking to unhosted.org for describing the goal of unhosted web apps that we try to achieve
* spec (probably only linking to W3C)
* everything about storage
* everything about apps (clients)
* dev team
* ...

[François Kooman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/12/12 9:24 PM, Jan-Christoph Borchardt wrote:
> remote storages: https://github.com/fkooman definitely has some,

> not sure which repo though ;) used by SURFnet

The php-remoteStorage one obviously, als also
html-remoteStorage-portal for the portal.

https://github.com/fkooman/php-remoteStorage
https://github.com/fkooman/html-remoteStorage-portal

Note that the php-remoteStorage implementation depends on the
php-oauth authorization server (https://github.com/fkooman/php-oauth)
and was only tested with this OAuth server, it may work with other
OAuth servers, but this is untested.

> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those

> which don�t want to do that we�ll still link, but it�s best to have
> it under one umbrella because it�s all about the same standard.

I'm okay with this, however, because of the OAuth AS dependency it may
be a bit weird to pull php-remoteStorage to the remoteStorage
organization and the OAuth server not... or is that not a problem?

Another idea I'm playing with is creating a "remoteStorage" VM that
has everything preconfigured. Would this be interesting?

Regards,
Fran�ois
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBQ6O4ACgkQh00UF7a4KpvIFACeMYFKIs1SdJeKRi8oOQhQEZ6U
kBcAn2PpRSHkCinxh1dD0Vn+yvhEh7fO
=11tW
-----END PGP SIGNATURE-----

[Mike Kazantsev]

On Wed, 12 Sep 2012 21:24:10 +0200
Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:

> So what do we have?
>

...
>
> remote storages:
...

> https://github.com/mk-fg/django-unhosted (Python)
>
>
> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
>
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.
>
> CC’d the authors – please let us know your stance on this.
>

From structural viewpoint I'm all for it, but not sure what that
transfer means from a technical perspective.
Probably a matter of reading the docs, but I thought I'll ask here
anyway.

Do github allow to retain admin access to a repo within organisation
without admin access to the rest of the repositories there?

How transfer itself should be performed?

Github won't let me transfer repo to an organisation unless I'm an
admin there, but granting me an admin privileges seem to be a totally
unnecessary overkill, if not a risk as well (if only because I might
leak my access due to poor security practices).
Though I guess such access will only be needed for a short time.


--
Mike Kazantsev // fraggod.net

[Martin Stadler]

Hi!

You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.

HTH,
Martin

[Martin Stadler]

I'd say if the maintainer wants to be part of the yet-to-be-formed Remote Storage organization/team it would be great to have the code in a repository in the github organization. Else we just link. (Not being closely related to the project in this way of course doesn't mean not being part of the Remote Storage community.)

Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:

[Mike Kazantsev]

It's not a transfer proper though - some github-specific metadata like
issues, watchers, stars, subscriptions, notifications, etc won't
be transferred.

Jan-Christoph has clarified that on irc (#remotestorage on freenode)
now that it should be done through admin access (and I've already
moved the thing).
I don't have a clear answer to other questions yet (again, should
probably just rtfm), but don't think they're as important.

[Jan-Christoph Borchardt]

If transfered through the admin settings of the repo, all the issues,
watchers, stars etc are also carried over. This is also the case with
your https://github.com/RemoteStorage/django-unhosted (see the 5
stargazers).

[Mike Kazantsev]

On Thu, 13 Sep 2012 00:08:16 +0200
Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:

> >> You can just push from your local git repository to the remote storage organization's on github. You can be granted commit rights for that without being an organization admin.

> > It's not a transfer proper though - some github-specific metadata like
> > issues, watchers, stars, subscriptions, notifications, etc won't
> > be transferred.
> >

> If transfered through the admin settings of the repo, all the issues,
> watchers, stars etc are also carried over. This is also the case with
> your https://github.com/RemoteStorage/django-unhosted (see the 5
> stargazers).
>

Indeed, but you must've missed the context of that (mine) response,
which was Martin's suggestion (above) to "push from your local git
repository to the remote storage organization's on github", which I've
(possibly mis-) interpreted as creating a new github repo and just
pushing all the same commits there.

[Sebastian Kippe]

What a lot of projects do for 3rd party repos is having a second organization suffixed with "-contrib", where all 3rd party code lives. That way it is clear for bystanders that the code has a bit of approvement by the project's core team, but is not maintained by them.

So, "remotestorage-contrib"?

> --
>
>
>

[nil]

+1

> --
>
>
>

[Jan-Christoph Borchardt]

I’d say we make it simple: You are part of the remotestorage org
either way if you contribute in a substantial way (such as writing a
storage). No need for a separate contrib group. And then everyone can
choose for themselves if they want to have the repo in the org or on
their own space.

On Sat, Sep 15, 2012 at 4:11 PM, Sebastian Kippe <in...@sebastiankippe.de> wrote:

> --
>
>
>