New Remote Storage Provider on Google App Engine using Google Accounts about remotestorage.io

[silverbucket]

Very cool! I think it's a great idea to ease the barrier for all the
existing gmail users. I signed up and did get the webfinger error at first,
but on the second try it worked fine.

On Sun, Oct 14, 2012 at 12:27 PM, shybyte [email protected] wrote:

On of the most important factors for adoption of remoteStorage 0.7 by end
users and developers is the availability of user friendly, effortless and
reliable remote storage 0.7 providers.

Unfortunately the current situation is not very satisfying.

Therefore and as a little programming exercise I developed this weekend a
new remoteStorage server. This new server is written in scala/java from
scratch and runs on Google App Engine. It uses google accounts for login.
This means that every one of the 350 million gmail users has now a remote
storage address ([email protected]). For more
information see https://remote-storage.appspot.com/ and
http://github.com/shybyte/remote-storage-gaehttps://github.com/shybyte/remote-storage-gae.

First, it might sound ironic to create a remote storage provider that runs
on google's server, but on the other hand it can lower the barrier to use
remote storage apps for the existing 350 million google account users.
Additional the code could be reused for another scala/java/jvm based remote
storage provider.

I tested it only with http://shybyte.github.com/unhosted-time-tracker/for now.
Is there any automatic test suite that can run against the server in order
to make sure that it is remote storage 0.7 compatible?
Should old pre 0.7 apps like shared stuff still run?

Please keep in mind, that the server is currently in early alpha and your
data is not save. In the near future this service will become a user
friendly, effortless and reliable remote storage provider for end users.

If you get a webfinger blablabla exception when you try to connect, please
try it again, or press reload and try to login again. I'm not sure if this
occasional bug is in remoteStorage.js or in the server. Could be caused be
the fact the the (https) connection needs sometimes some time to build up.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7.

[shybyte]

I analyzed the webfinger error and opened the issue remotestorage/remotestorage.js#109 therefor. It's caused by slow app engine cold starts, but slow web requests needs IMHO generally a better handling from remoteStorage.js.

@michielbdejong @nilclass I'm still wondering if there exist an automatic test suite that can run against a server in order to make sure that it is remote storage 0.7 compatible?

[nilclass]

@shybyte no, there is no such thing yet, but it is planned.

[peacekeeper]

This is nice.. I tried the Time Tracker and it worked just fine.

My understanding is that 0.6 and 0.7 are not compatible, i.e. I can't run
0.6 apps with the 0.7 storage, and vice versa, right?

Would it be possible to have BOTH a 0.6 and a 0.7 storage associated with a
single address?
Or is there something in the respective Webfinger/Discovery processes that
prevents this as well?

Markus

On Sun, Oct 14, 2012 at 2:27 PM, shybyte [email protected] wrote:

On of the most important factors for adoption of remoteStorage 0.7 by end
users and developers is the availability of user friendly, effortless and
reliable remote storage 0.7 providers.

Unfortunately the current situation is not very satisfying.

Therefore and as a little programming exercise I developed this weekend a
new remoteStorage server. This new server is written in scala/java from
scratch and runs on Google App Engine. It uses google accounts for login.
This means that every one of the 350 million gmail users has now a remote
storage address ([email protected]). For more
information see https://remote-storage.appspot.com/ and
http://github.com/shybyte/remote-storage-gaehttps://github.com/shybyte/remote-storage-gae.

First, it might sound ironic to create a remote storage provider that runs
on google's server, but on the other hand it can lower the barrier to use
remote storage apps for the existing 350 million google account users.
Additional the code could be reused for another scala/java/jvm based remote
storage provider.

I tested it only with http://shybyte.github.com/unhosted-time-tracker/for now.
Is there any automatic test suite that can run against the server in order
to make sure that it is remote storage 0.7 compatible?
Should old pre 0.7 apps like shared stuff still run?

Please keep in mind, that the server is currently in early alpha and your
data is not save. In the near future this service will become a user
friendly, effortless and reliable remote storage provider for end users.

If you get a webfinger blablabla exception when you try to connect, please
try it again, or press reload and try to login again. I'm not sure if this
occasional bug is in remoteStorage.js or in the server. Could be caused be
the fact the the (https) connection needs sometimes some time to build up.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7.

[nilclass]

Actually 0.6 (spec version 2011.10) uses different attributes on the remotestorage link in webfinger than 0.7 (spec version 2012.04).
So it is possible to advertise both on the same user address.

In addition, if your storage provider's auth server supports the old "scope" format (i.e. categories separated by comma, without explicit mode) it should be possible to use a 0.7 storage provider for 0.6 apps. However, data stored by 0.6 apps may cause problems with future 0.7 apps working in the same folders, as 0.6 data doesn't necessarily have correct MIME types and (in case of JSON data) @type attributes.

[michielbdejong]

oh, awesome! sorry for not reading this earlier, i was offline for a bit. i tried it out and was not really able to use it, but got a lot of 'offline' in the widget, and photos i upload through Sharedly become 404s. but i guess my connection here is not very fast, and maybe also appspot is timing out, so anyway, great stuff! :)

So iiuc you as the AppEngine app publisher are paying for the storage of everybody, right?

btw, here's a blogpost from apparently one of the people who built AppEngine:
"Unhosted [...] I’m intrigued. We originally considered structuring App Engine‘s datastore the same way, clustered by user instead of by app."
http://snarfed.org/2011-12-31_unhosted_decoupling_web_apps_from_storage_providers

[michielbdejong]

we should add this on http://remotestorage.io/get/

[shybyte]

Actually I have to improve this a lot when I am back in Germany. Until now its more an experiment not really ready for the public. Its also just using the free app engine quota.

[kerbymart]

@shybyte I forked your remoteStorage GAE "backend", do you have a Java version of this or just scala?

[shybyte]

@kerbymart There is just the scala version, but i can really recommend to learn scala. Please keep in mind that this remoteStorage GAE "backend" supports only a pretty old version of the remote store protocol which was up-to-date 2 years ago.

[raucao]

Would be great if someone wants to work on updating this! If you have questions about the protocol requirements or server implementation details, we'll be glad to help you anytime on IRC (#remotestorage on Freenode) or the forums.

[kerbymart]

@skddc Yup I'm interested in making remoteStorage work with GAE backend (Java)

[raucao]