@zatvobor that’s marvelous. Something I have in mind is a reference implementation for http://nobackend.org/ - but I’m busy with other stuff, so feel free to to jump in and we can get listed there!
I was also thinking of building a pouchdb adapter of some sort (not exactly sure that’s the right angle), which allows you to replicate a pouchdb to maidsafe. Not gotten around to looking into that in detail yet though .
The question of how a web app built with modern Javascript/RoR/… frameworks can live server-less in the browser and use the SAFE network for persistency and interaction with other clients also bugs me for a long time now. And the SAFE community didn’t find an answer to it yet, at least none that I am aware of. Please correct me if you have more insights than me.
Building a PouchDB-based layer for API-style interaction between a Javascript client-side app and the SAFE network is a worthwile goal! (In terms of simplicity I dream of an RoR-activerecord-like abstraction to interact with SAFE as an app developer!)
@happybeing and @lightyear, please let me know when your thoughts become actions…maybe i would join you.
@mabe I’m currently looking at adding a SAFE back-end to remoteStorage which does what you seek: works offline and automatically syncs with the back-end. It uses browser offline storage rather than PouchDb, which means it is less powerful but - fingered crossed - easier to implement.
I’m still investigating at this point so am not sure how hard or easy this will be, but would welcome others helping with this as I’m still learning JavaScript and don’t have loads of time. So if you are interested, let’s get our heads together - anyone else welcome too!
That sounds like an interesting (and sane) approach. I was briefly looking at the (current) spec and I think it shouldn’t be too hard to even have the launcher expose such an API per default (including the shipping of the currently supported remotestorage.js) not sure extensibility of the launcher is on the plan right now though. However, remoteStorage.JS seems to extensible by itself, and from looking at the existing backend-implementations, it shouldn’t be too hard to get one up for safe!
No. But that is also – from our perspective – just a glorified one-level-FS-system with specific rules on format and how to keep track of things. I was actually looking into the replication algorithm earlier and it really shouldn’t be too complicated to emulate that via a filesystem (and therefore ontop of maidsafe) – only problem is the usual: locking in a distributed system .
Not sure if I understood you correctly (totally new to remoteStorage), but basically you are proposing two approaches, right?
Integrate remotestorage.js into launcher: A Javascript app directly communicates to launcher in a remotestorage.js-fashion.
Extend/fork remotestorage.js: A Javascript app communicates to extended remotestorage.js, a SAFE-enabling localStorage-adapter communicates to lauchner.
In both cases the main task would be to code that safeStorage-adapter, right? Please correct me if I got you wrong!
From what I understand you wouldn’t need to fork/mess with remotestorage (RS) itself, you could just provide the provider as a separate module – remotestorage is designed in a way to allow that easily.
For me the killer feature for a higher-level JS API kinda-baked-into-Safe would be to encourage good citizenship by the App/Tooling and more over offer offline-first capability. If MS came with an API for that, that’d be a major game changer!
@mabe@lightyear and @zatvobor in case you want to get involved in work on remoteStorage we can carry on our discussion in the SAFEpress forum remoteStorage discussion rather than derail this topic. We could have a topic here but I’d like to spark some life into the SAFEpress forum if possible, and SAFEpress is my ultimate (if overly ambitious for just me) destination!
I have not done much yet, so it is open for anyone to hack code etc. When I have any code to share I’ll push it to my repo, but I’m happy to be overtaken by anyone who knows JavaScript and so on better than I.
@lightyear I thought it was necessary to hack remoteStorage.js itself so you you may already be ahead of me there. I’ve been looking at the support it has for Dropbox and Googledrive (both unsupported pre-alpha code) and was planning to follow that, but if you’ve found a better method I’m all ears.
So any of you are welcome to jump in if you’re interested, otherwise I’ll plod along and see how far I can get with a crude backend and share anything useful I can create, in that unlikely event
ed it! Keep it up!
.
.