Which is fine but as you suggest the question of how a non-js app will talk to the network is now not obvious. Rationale for using node.js perhaps just naturally follows from its being good for network environments but I’m guessing at the missing link atm…
and e.g. python can do it too via its C-API modules ( cffi / cdll )
(if you are a better python programmer than i am and can define the inputs in the correct way that would make one more line for a real python-program authentication there:
what can be seen on that screenshot is a modified authentication function with pre-defined app/vendor name and version … but really called from python)
Me too… but I got them working because rest is a widely understood concept and I can patch together examples and polish those together. Now I’m looking at a blob of safe_client_libs and back at square one for what that might want as input. I guess it’s a hurdle that only needs jumping once; so, if anyone does that in rust, it would be useful to see that.
yeah - someone needs to take the library and put together a wrapper around it … so that the necessary variables for the functions get transformed into the correct C-Types and pushed to the library -> &the output back into python variables
Unless I’m terribly mistaking now, it’s been made clear in several previous dev updates etc that the new FFI bindings in safe client libs can be ported to any language. They are just doing a node.js versjon right now.
So correct me if I’m wrong, but an API like the node.js one can be made for pretty much any language?
Let’s have a list of volunteers and/or suggestions about who would be good and I’ll see what can be done. I’ve been a bit less immersed lately, partly due to other things happening, and partly because it’s getting over my head on the nitty-gritty level.
So you guys who’ve been participating and have stuff to offer, let me know. We can do a medley.
It’s possibly not clear how this picture is. There is a structure like this
3-> [node][python][java]... Almost any language
2-> FFI Layer (essentially a "c" interface)
1-> Rust (safe_client libs)
1-> rust apps can use the rust layer directly.
2-> FFI (foreign function interface) really only exposes a “c” interface which allows “native” libraries for a lot of languages to “import” into other programming languages
3-> Libraries already prepared and packaged for other languages. We only have node at this time, but nothing stopping us having java python lua etc. (except time)
Our goal here is to do similar with this as other projects do and as we are trying to do with our “demo” apps or example code snippets (we struggle with the demo app name a lot) and have community maintained native bindings. I suspect we may end up as maidsafe having node/python/java libraries and have these built and deployed via our CI scripts. It’s a debate in house though (rightly) as to how much we take devs off launch to do this right now.
This might sound a bit crazy, but could I use the SAFE Client FFI bindings in a closed-source rust library with it’s own FFI bindings which are used in a closed-source SAFE app written in node?
Would this avoid a licensing issue compared to importing the SAFE Client libraries directly into a closed-source rust library with it’s own FFI bindings which are used in a closed-source SAFE app written in node?
The FFI bindings are not bsd/mit licensed, so you can do as you wish there chap Good luck with everything, I hope you enjoy and give feedback to make these libraries as useful as possible for everyone.