Is a central storage area planned?

[David Benson]

This is a high level dev question, eventually, I just need to explain some background first.

We've built a diagramming app called draw.io (www.draw.io), but we've really just built the app, we don't do storage or user management. We integrate with cloud storage providers that allow the auth and persistence to be done fully client-side (Google Drive and Dropbox as of now). We get constantly asked for a solution that lives behind the firewall, but it doesn't make sense to have a DB and web server for one app, then more for another, etc. So, obviously we've been looking for a solution like this.

From my reading through the project docs, at a high level sandstorm provides containerization for apps and SSO, but the idea with the app data is that it lives in with the apps. That does present us with the problem of storage, which we could technically solve, but we were hoping that such a solution would offer a central storage area for all apps.

I saw on one of the articles about SS:

"There will be unified login for all the apps, and while each one runs in its own sandbox for security’s sake, it’s possible for them to share data, so you can use a photo from a storage app in a document app, for example, or a contact from an address book in some social app."

So, shouldn't a "storage app" be part of the core functionality? It doesn't feel like it'd make sense to possibly fragment storage solutions. Unless storage apps had a fixed API to work against, general apps might have to write integration code for each storage app to get access to the data.

There's also a backup issue. Currently, you'd be looking at backing up the entire machine taking the apps and their data in one big block. A central storage area could mean you could backup just the data. And yes, I am thinking something that looks similar to the Google Drive SDK. It would require more integration effort from the devs, but the result more be more appealing to an Enterprise environment, but the integration can be entirely optional.

Obviously, there's a ton of stuff for you to do, but is this something planned at any point? Even if it's just a very simple solution that uses, maybe, http://remotestorage.io/ ?

[Kenton Varda]

Hi David,

draw.io is really cool! Using it for ten seconds, I can already see that it does a lot of things far better than, say, Google Docs' diagram tool. I would love to see this running on Sandstorm someday (and would happily pay for it from the app store).

Sandstorm is actually designed such that apps like yours shouldn't need to talk to a storage API. Instead, we turn everything upside down: your app is the file being stored. Sandstorm is designed such that not only does every user have their own instance of an app, but each document is actually a separate instance. This especially makes sense for apps like draw.io, which have a strong sense of documents. Each diagram would live in a separate sandbox.

Thus, Sandstorm can already treat your app instance as a "file". You can remove the "open file", "save file", "make a copy", etc. functionality from your interface, as it's already handled by the system. Sandstorm even already provides a way to download an app instance as a file and then upload it to another Sandstorm server (one of the buttons on the top bar). Apps don't have to write any code to make this work.

Of course, the other place where you use a storage API currently is for importing components to be embedded into a diagram, e.g. images. Sandstorm will solve this problem using the Powerbox, a general "picker" UI supplied by the system. Instead of coding up your own picker against some storage API, you would simply tell the system "I need an image", and then Sandstorm will display an interface to the user to choose the appropriate image and give it to you.

This way, you don't have to ask the user for full access to their storage. FWIW, I personally would be pretty uncomfortable giving draw.io access to my Google Drive, which I also use to store things like confidential legal/tax documents, encryption keys, etc. So for users like me, the powerbox UI also gives us more protection, which makes us more willing to use apps from smaller developers.

BTW, while Sandstorm implements its own file management interface (an early version of which you can see in the demo; https://demo.sandstorm.io), the model also makes it possible for an app to serve as an alternative file manager. The only "API" the app needs to implement is a picker UI to be embedded into the Powerbox flow. This picker UI could work in arbitrary ways. Maybe one app could implement folder-based organization while another implements labels and a third is entirely search-based.

One last thing: We are actually working on a hack for Sandstorm apps to use which will monkey-patch the browser's localStorage API and automatically sync it back to the server. I see that draw.io can already use localStorage, so with this hack, porting to Sandstorm is likely to be pretty trivial. :)

Does this make sense? Any objections?

-Kenton

--

Sandstorm.io is crowdfunding! http://igg.me/at/sandstorm

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Benson]

OK, that's pretty clever :). No objections, it sounds simple and simple is best 99% of the time.

Yes, the generic picker is the one other thing that'll be needed, but we support stuff like DnD images into the diagram, that'll do to start with.

In terms of Google Drive, your ex-colleagues are smart cookies :). There's a permission on Drive that only allows an application to access files it's created or the user has explicitly directed the application to open. This is the permission draw.io uses, so it's unable to open any other document type (there's the Google image picker for images, but that's another explicit permission just for images). It's a very well thought out API, beats Dropbox into submission.

But, we've probably spent 2-3 months in total on the Drive integration, getting all details pinned down. A lot of integrations focus on reducing friction for users, the kind of reductions in dev time we're talking about here are very interesting.

But overall, love the idea, I'll give the crowdfunding a little nudge.

David

[Kenton Varda]

On Tue, Aug 5, 2014 at 1:14 AM, David Benson <david...@gmail.com> wrote:

OK, that's pretty clever :). No objections, it sounds simple and simple is best 99% of the time.

Yes, the generic picker is the one other thing that'll be needed, but we support stuff like DnD images into the diagram, that'll do to start with.

In terms of Google Drive, your ex-colleagues are smart cookies :).

I actually spent three years working on access control infrastructure for Drive and other Google products. So, some of this is my own doing. :)

 

There's a permission on Drive that only allows an application to access files it's created or the user has explicitly directed the application to open. This is the permission draw.io uses, so it's unable to open any other document type (there's the Google image picker for images, but that's another explicit permission just for images). It's a very well thought out API, beats Dropbox into submission.

Yes. Though, when I tested this earlier, I saw that draw.io was requesting permission to do something like "manage my photos on drive". I actually didn't quite know what that one meant, but it sounded like "full access to my photos".

The "permission to access files created by this app" approach is certainly a lot better than the more common "access to everything". But, it always felt like a messy hack to me, because it still treats the app itself as a singleton, when it doesn't need to be.

 

But overall, love the idea, I'll give the crowdfunding a little nudge.

Thank you!

-Kenton

[David Benson]

On Tuesday, 5 August 2014 09:42:43 UTC+1, Kenton Varda wrote:

Yes. Though, when I tested this earlier, I saw that draw.io was requesting permission to do something like "manage my photos on drive". I actually didn't quite know what that one meant, but it sounded like "full access to my photos".

The "permission to access files created by this app" approach is certainly a lot better than the more common "access to everything". But, it always felt like a messy hack to me, because it still treats the app itself as a singleton, when it doesn't need to be.

It is a bit hacky in parts. My major beef with it is if you share a file in Drive with someone else, they get an email with a link to the diagram. They click on the link and the permissions fail because the user has never explicitly opened the file via the Drive UI. The only way around this is to give the app full permissions to your Drive, which, as you say, is plain wrong.