Consider simplifying the feature loading mechanism

[michielbdejong]

The feature loading seems very complicated. All we need is:

• a global remoteStorage object, which can simply be created whenever src/remotestorage.js is evaluated (we don't really need RemoteStorage to exist as a class)
• instantiate remoteStorage.local dynamically based on whether IndexedDB is available
• instantiate remoteStorage.remote dynamically based on which backend is used
• fire ready
• instantiate baseClient dynamically during defineModule

All other classes (sync, authorize, discover, access, widget) can be instantiated as remoteStorage.access etc. during evaluation, provided src/remotestorage.js is included before e.g. src/access.js. They can receive a pointer to the remoteStorage object, so that e.g. sync can refer to this.storage.local etc. in its code, like it does now.

Evaluating remotestorage.js (at the point where the script is included in the page) should make the whole API available instantly, this means that somewhere between the baseClient and the local store, there probably needs to be a queue of requests that can be serviced once the local store is ready.

For the nocache build we can just create a config variable. We already have a check in the baseClient (actually it's in src/remotestorage.js) that checks if remoteStorage.local is defined, and if not, goes straight to remoteStorage.remote.

For nodejs we have the environment check that automatically notices when it's not in the browser.

So if we keep remoteStorage.local and remoteStorage.remote dynamically loaded, I think the rest can be simplified a lot.

[michielbdejong]

Maybe a good opportunity to switch to ES6 modules as well!

[raucao]

Sounds great!

[silverbucket]

I think it's important to keep the RemoteStorage factory constructor.