ah if only we knew that before we started we do like a challenge lol but yeh while the issues in routing / crust kind of blocked network related testing/progress during the sprint these issues were very much unexpected and are seemingly complex too since guys in those libraries are still working through them right now.
We havent yet chalked the network objective to the next sprint as there are currently a few things making this week quite hectic. To name a few, routing handover with ben leaving at the end of the week and getting andrew into the routing library with Brian. CRUST RFC that andrew has been working on which touches on quite an extent of the crust library for updates. This RFC itself again reduces code complexity a lot while also hopefully getting the library more rust language friendly. While both of these are ongoing this week, guys in the networking libraries are also working on the above mentioned bugs in CRUST and routing. Now if they end up getting resolved in the next few days, you guys will surely be the first to hear about it and we will accordingly try and get the vault library tied in to get the rust-5 deliverable out. If not, then with the handover complete, weāll be prioritising on getting the networking layer solid to get the previously planned deliverable out before adding more intersecting features as you can expect.
By Drive, if you mean NFS (which isnt just the VFS portion), then yep and also the DNS crates. Launcher RFC lists the actions it currently supports from any app communicating with it.
Can answer these two together. Yes when new features are added in the core modules, the launcher API will also be extended to allow access to those features from apps communicating via the launcher. This will be with new RFCās for discussion and implementation phases. As for documentation and guides/usage samples itself, you can expect that start making their way outside RFCs too, such as from the launcher repo documentation / dev site and so onā¦
We had the firefox addon compiled today from all three desktop platforms with the latest master branch of safe_ffi. Maybe worth a try again to see if youāre still having issues Mark. @ustulation / @Krishna_Kumar should be able to help you out if youāre still having issues.
Think this might be soon actually. As mentioned in the update, you can expect a RFC from spandan which should propose the spec to get the launcher to support anonymous data access via the launcher. This should then remove the dependency the browser addons have on the safe_ffi module and bring them to a similar footing to standard desktop apps.
Yep and none launcher pretty much disconnects the network workings/dependencies from app devs, so essentially when the mock network is replaced with the real network version, only thing thatād change is the launcher binary that which is run on the users machine. App code talking to the launcher will be identical but now with the new version data sent to the launcher by the app instead of getting stored locally in the machine will be sent to the network and retrieved from the network accordingly.
What if I donāt want to run āwebā app but rather software app, would it be possible to work on software apps on top of safe? I am not a big fan of javascript.
dns_example is not really a āwebā app. Itās a standard desktop app that uses Javascript as itās programming language similar to many of the apps listed on http://electron.atom.io/
However, youāre not confined to any programming language to build apps with. nfs_example here is a rust app which also communicates with the launcher similar to the dns_example but ofc from a different language.
As long as the IPC with launcher is established as detailed in the launcher RFC, youād be sorted to choose whichever language you prefer for the app let it be python/java/c#/c++/ā¦ Weāll be adding more examples ourselves too to the safe_examples repo.
Electron is a framework built on nodejs, formerly known as atom. Electron framework facilitates desktop applications to be built using nodejs. Electron makes it really easy to cross compile to all 3 (OSX, windows and linux) platforms too.
Nah all paths referred to in the Launcher IPC for JSON data are paths on the network. VFS apps can then choose to mount those network folders as local folders via libraries like FUSE.
But thereās no way to do this yet, or am I wrong!?
And thanks for responding (and @krishna to me directly) to all my questions. All very helpful
@smacz, and anyone else - are you interested in working towards understanding what Structured Data can do and creating some kind of testbed to play with it? It looks like we have the option of another go at safe_firefox_addon plus extending safe_ffi (tricky but would mean we have a compiler-free/in browser testbed, and something easy to build on for web apps like SAFEpress) or jumping on the JSON API as it emerges (with the option of pestering @ustulation as a bonus ).
It would be good to work with others interested in these areas so let me know if you want to be involved, or just know what I am up to.
Youāre right(partially ) as in there isnāt an app yet that does this and expose a VFS, however such an app should be possible to code with whats currently exposed from the launcher JSON API. Itās now just a race if the client guys end up creating such an app with the launcher API to expose a VFS drive or someone from the community beats them to it
Iād definitely suggest pursuing this route, as itād help everyone more in the long-term. With the FFI dependency soon to be removed from browser addons, extending the FFI layer might not be of much use to scale. Also the benefit of pestering @ustulation / @Krishna_Kumar is a definite bonus On a serious note though, Spandanās RFC to get the anonymous access to data via launcher should be getting published to the RFC repo very soon which should trigger a bunch of questions/scope discussions. So Iāll definitely suggest participating in that to make sure you guys are getting your required features catered for with that RFC. If needed we can also setup a mumble chat with the client guys while that RFC is getting discussed to ensure required features are getting catered for.
Nooooo! Donāt go!!! Will you be developing apps for the network?? Youāre such an asset to the project, I appreciate your contributions to the libraries. But youāll be starting your own safe pod and teaching others to commit to core libraries?
we do like a challenge lol but yeh while the issues in routing / crust kind of blocked network related testing/progress during the sprint these issues were very much unexpected and are seemingly complex too since guys in those libraries are still working through them right now.
launcher pretty much disconnects the network workings/dependencies from app devs, so essentially when the mock network is replaced with the real network version, only thing thatād change is the launcher binary that which is run on the users machine. App code talking to the launcher will be identical but now with the new version data sent to the launcher by the app instead of getting stored locally in the machine will be sent to the network and retrieved from the network accordingly.
On a serious note though, Spandanās RFC to get the anonymous access to data via launcher should be getting published to the RFC repo very soon which should trigger a bunch of questions/scope discussions. So Iāll definitely suggest participating in that to make sure you guys are getting your required features catered for with that RFC. If needed we can also setup a mumble chat with the client guys while that RFC is getting discussed to ensure required features are getting catered for.