Currently the c-bindings are in the works - what is the planned Output? Will there be a DLL for every CPU-Architecture?
(Testing this Forum - if this Topic is not relevant, remove it ).
Currently the c-bindings are in the works - what is the planned Output? Will there be a DLL for every CPU-Architecture?
(Testing this Forum - if this Topic is not relevant, remove it ).
Bindings and connectors are in the works, but we are also open to community collaborations. I think this is a good example of how we can improve communications a Storj, to make it easier for people in the community to contribute.
I can bring this up to the product manager in the meantime!
@topperdel another thought about bindings. I would naturally like to see them come from the community. I also think that if that’s the case there should be a storj engineer internally who is a liason, because specs and review… I have talked about this previously with our CTO and also the VPN of engineering and the VP of operations… I need to reopen this conversation to loop in the new product manager we’ve added, because managing the process is something storj should be helping with and not placing on the shoulders of anybody else. I would prefer for people who are contributing code to be able to focus on the coding.
I’m visiting the branch office next week and will be seeing what can be done to coordinate the process in the best way
I would love to help with the .Net-Binding. Let me know, if I may help or if there are things you need to know.
From my point of view it would help to get an answer about the c-binding-result. My tests with an own implementation lead to the conclusion, that I would need a DLL for every architecture my wrapper/binding should provide (x86, x64, arm and so on). So if this is the target for the c-bindings, I’m happy. I would do a one-to-one-wrapper for the libuplink-functions as well as a “simple” or “convenient”-version for the basic tasks (listbuckets, createbucket etc).