Continuing the discussion from Setting up a remoteStorage.js development environment:
In the past, we had an unwritten, yet rather clear policy of not adding new dependencies to remoteStorage.js, unless absolutely necessary.
In fact, we’re already planning to remove the biggest one, Bluebird, because not only is
Promise a standard now, integrated directly in modern browsers, but also if a developer wants to shim it, they will likely choose a library themselves, that does so across all of their app code anyway, so Bluebird would both add to the size as well as potentially interfere with that. (localForage actually offers seperate builds with and without promise shim for that reason for example).
That said, I personally think it’d be useful to break up remoteStorage.js into smaller components eventually and share more code with other projects.
Now, regarding the SAFE addition in particular (all just my own opinion, not speaking for anyone else here):
- We should probably solve the Bluebird issue in the same go, while adding SAFE. At the end of the day, we only need standard promises, without fancy extra features that are not part of the spec. I think any SAFE code should be fine with that as well
- The safenet library looks too big and multi-purpose to pull the whole thing into remoteStorage.js from what I’ve seen on first sight.
- For some things I don’t know what they’re for (DNS features e.g.), for others I think it’s duplicating existing logic (checking for existing auth e.g.)
- I don’t know why someone would want to encode/decode binary data in/from base64. Might make sense for some apps, but those could pull it in themselves. Maybe there’s a reason for safenet to include it that I can’t see.
- Using Fetch (via isomorphic-fetch) is a good idea for new libraries, but it’s more of a personal preference than a necessity there. We’re fine with regular old AJAX and as SAFE seems to offer an HTTP API, I think we should use the same mechanism for SAFE requests as for the others. Not withstanding the fact, that I think we should eventually update all code to use Fetch anyway. But it’s a bit early for that imo, as it only works in two browsers as of yet.
- tweetnacl seems small enough to pull in as a new dependency if needed for SAFE operations. I thought the SAFE Launcher would take care of crypto, so I’m not sure if it is necessary to have for using the API.
In summary, and looking at the SAFE Launcher docs, I think we should not pull in that library, but rather program SAFE support using the launcher API directly, and pulling in new dependencies to remoteStorage.js only if we deem them necessary for implementing SAFE operations. I think the Launcher gateway API looks straight-forward enough to implement it directly in the SAFE backend class.