I'm not the author of this, and I'm still trying to wrap my head around how it works, but one potential use for it in the future might be essentially a browser-based application platform. Visitors could run, edit, create, and host their own web applications. But it's still very early in development - there isn't a security model yet, other than sandboxing user-generated scripts using Web Workers. There are some sample apps like an RSS reader and so forth here: http://grimwire.github.io/grimwire/#_apps There was also an article on Mozilla about it a couple months ago: Building User-Extensible Webapps with Local https://hacks.mozilla.org/2013/03/building-user-extensible-w...
Hi edtechdev. I'm the author of grimwire - thanks for posting.
You have it pretty much covered. The intent is to use REST as a unified interface for remote services and local programs, much like Plan9 did using the file-system. The Worker programs should be compact, stateless Webservers that can be reconfigured into multiple use-cases. You can compose by doing things like embedding (UIs should be self-contained) hypermedia discovery (using programmatic link navigation) and proxying. I'd like for it to be possible to take (eg) an inbox interface program and attach it to a bash-piping backend (rather than a webmail host) to create an in-browser CLI. Not sure if that's a good idea or not, but you get the idea - a good grim app can bend.
The other major goal is to detach the Web app frontend from the back - to improve privacy, to let users improve their Web software, and to enable decentralized architectures (which I talk about in the article). A major factor in doing that is the security model, which would have to become more fine-grained than the single-origin policy. Web Workers make it possible to run untrusted code, and privacy policies can be built by monitoring HTTP traffic (all of which go through the document) but I should make it clear that there's a lot of work to do on security still, so stay away from untrusted code when you use grim 0.1.
I've still got about a month of shaping up to do, including doc-writing and getting some pre-freeze feeback from devs. The only documentation that's current is in the build (http://grimwire.github.io/grimwire/) and it's in progress. Please ignore everything else, including the stuff in the GitHub readme and wiki.
If you're in Austin, I'll likely be speaking at next month's JS/Node meetup (http://www.meetup.com/noders/) so please join us.
> The backend is written on NodeJS and Redis, and will include Web APIs for users, permissions, email, and application storage with the remoteStorage protocol.
Is grimserver a hard dependency, or just an implementation of some example APIs? Could one disconnect the client and depend on different providers for auth, email, chat, etc.?
9 comments
[ 2.9 ms ] story [ 33.3 ms ] threadPageForest is another site that lets people create their own javascript applications, hosted on appengine: http://www.pageforest.com/ And other sites that let visitors create and host their own apps or games include http://pixieengine.com/ http://www.playmycode.com/ and http://scratch.mit.edu/
There's some more info about Grimwire here: http://grimwire.github.io/grimwire/
You have it pretty much covered. The intent is to use REST as a unified interface for remote services and local programs, much like Plan9 did using the file-system. The Worker programs should be compact, stateless Webservers that can be reconfigured into multiple use-cases. You can compose by doing things like embedding (UIs should be self-contained) hypermedia discovery (using programmatic link navigation) and proxying. I'd like for it to be possible to take (eg) an inbox interface program and attach it to a bash-piping backend (rather than a webmail host) to create an in-browser CLI. Not sure if that's a good idea or not, but you get the idea - a good grim app can bend.
The other major goal is to detach the Web app frontend from the back - to improve privacy, to let users improve their Web software, and to enable decentralized architectures (which I talk about in the article). A major factor in doing that is the security model, which would have to become more fine-grained than the single-origin policy. Web Workers make it possible to run untrusted code, and privacy policies can be built by monitoring HTTP traffic (all of which go through the document) but I should make it clear that there's a lot of work to do on security still, so stay away from untrusted code when you use grim 0.1.
I've still got about a month of shaping up to do, including doc-writing and getting some pre-freeze feeback from devs. The only documentation that's current is in the build (http://grimwire.github.io/grimwire/) and it's in progress. Please ignore everything else, including the stuff in the GitHub readme and wiki.
If you're in Austin, I'll likely be speaking at next month's JS/Node meetup (http://www.meetup.com/noders/) so please join us.
#include "page2"
----
God's temple
Is grimserver a hard dependency, or just an implementation of some example APIs? Could one disconnect the client and depend on different providers for auth, email, chat, etc.?