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.
The feature loading seems very complicated. All we need is:
remoteStorage
object, which can simply be created wheneversrc/remotestorage.js
is evaluated (we don't really needRemoteStorage
to exist as a class)remoteStorage.local
dynamically based on whether IndexedDB is availableremoteStorage.remote
dynamically based on which backend is usedready
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.