Having started to access the latest SAFE nodejs APIs in the browser I’m wondering how this is likely to develop, because the SAFE CLI is not yet capable of certain operations, such as putting content directly to a file rather than uploading from the file system. In fact I don’t think it offers any functionality for creating, modifying or deleting files unless you go via the device filesystem.
So my first question is whether this will be added as an extension of the SAFE CLI style ffi, or if a separate API is planned, and if so can you share any thoughts on this?
I’m assuming that there will be ffi access to the lower level APIs for manipulating the SAFE data types directly, so that for example, an app could manipulate file container objects itself but I wonder if it makes sense to provide an API for this too. That might be simpler to use, as well as ensure that the results are compatible with the CLI based API.
In the short time I would love to have the CLI style APIs extended to allow file containers to be manipulated directly, for example to save data to a file, delete a file (e.g. safe_files_new, _update, _delete etc.). This would enable many simple apps to be created fairly easily, pending more comprehensive APIs becoming available.
Extending the CLI model might not be that great for more general application use cases though, I’m not sure which is why I’m wondering if a separate API that is less CLI like might be being considered.
My second question is about how support for private data will be provided in the API? This also impacts the CLI of course as people will want to upload and access their private files using same CLI.
Everything being public is not going to be enough to keep us happy for long!
I realise this may be a bit down the line so no worries if there’s not much you are able to share yet. I’m keen to demo apps up to the level we had on alpha2 ASAP so consuming things eagerly as they appear and trying to help with feedback and wants!
As per being all part of SCL, it could be, but if we get the most commons abstractions in this crate you shouldn’t need any of the current SLC API, only if you are trying to read/write data not following these conventions/specs is that you’d additionally need those other APIs to be also included in your app.
Yes, I think we should be able to expand/evolve it to support many things, in the same way as exposing more granular/control over data, there are others who are also imagining commands with even higher abstractions, e.g. a “deploy” command which enters like an interactive mode asking for details and doing everything for you under the hood. So, I personally believe is not really what but when, i.e. priorities for covering the most common use cases first. This is what I like about CLIs in general, you can keep expanding it without affecting other users and their use cases.
For private data, in the early thoughts we imagined that most/all commands work the same way, or very similar, and adding some flag to them, where the default is private and you specify --publish, or the other way around, e.g. files put ./my-local-folder --private, and something along the same lines for the APIs, but there are a lot of details to go through, and the same applies to encryption and sharing private data.
Just in case, this is true, we prepared the API (files_container_add_from_raw) and JS binding for this particular case though, so it’s just about exposing it from a command in the CLI, look at these tests for examples of how to use it from js: sn_nodejs/test/files.test.js at master · maidsafe/sn_nodejs · GitHub
Along these lines, I made a little PR to safe-cli that enables reading data from stdin when calling safe files add. So basically it exposes files_container_add_from_raw() to the CLI user.
