the upcoming version of remotestorage.js, v0.8, has support (technically) to be used without modules (so just as what we call a ‘base client’), and even without caching (so then all that is left is what we call the ‘wire client’). I would propose not to promote use of the base client so much, as it would make it too easy for people to reinvent the wheel instead of reusing the existing modules from other apps. The wire client could however be useful when constructing a storage backend for a client-side framework like backbone or nimbusbase. Such frameworks usually already handle caching.
Where/when was there a discussion about 0.8 features? I don’t remember anything ever being decided about exposing baseClient directly to apps without any use of modules. I think this is us being lazy and not making efforts to make it easier to write modules and complete what we’ve started.
If we go down this route, what’s to incentivize anyone to take extra effort and time to write a module?
What is the case for exposing the base client? Why was it determined we needed to do this for 0.8?
the baseclient discussion was part of the email thread titled “remoteStorage roadmap and tasks”. iirc and iiuc, @jan and @xMartin were in favour of exposing it, @raucao and you were against, and @nilclass and i were both a bit “yeah but no but” about it. 
@nilclass and i then had a discussion IRL about it, and decided modules, and not the baseclient, should (still) be the thing we show developers in the “getting started” guide.
if anyone thinks we should start promoting the base client in the getting started guide, then we can open a discussion about what to show in the getting started guide, but i don’t think that is the case?
because multiple people asked for it. we tell everybody to use modules, but then a percentage of them will say “i just want to store the f***ing data”. and to those people until now we have said “write a module and call it after the name of your app”. it seems more natural to just give them the baseclient, because that is what they are actually asking for.
Yes, modules should be optional. The whole modules thing slows down the remoteStorage universe too much. Hoodie will solve the famous 80% of what developers want while it is still discussed how remoteStorage(.js) can solve 100% of the problems the web has.
I’d like remoteStorage to let you “store the fucking data”, plus doing so per-user if you want this.
I want this to be the focus. All the other great ideas can be done later.
There’s no need to do it later. And yes, it’s good to have a BaseClient available in general. For example our Ember-Data adapter is using it. However, it’s also using schemas, and I think that’s the critical part. If you’re going to use the BaseClient for whatever reason, it should still be easy to use the common data formats. No?
I don’t know the implications of that. In general I would say, if using common data formats requires an extra effort for a developer it is ok as you’re also getting something for that. While if you don’t care about that (at the moment or in general) it shouldn’t be in your way.
Just because it’s easy to use it doesn’t automatically make it stand in your way or harder not to use it. I don’t understand what your point is.
If in the end both ways are super easy there’s nothing to argue about. In my experience this is not always the case and usually you have to prioritize to get something done. That’s why I said what what my priority would be. After all I understood one of this thread’s questions as what approach to focus on when communicating with app developers.