Open-Transactions democratizes financial and monetary actions. You can use it for issuing currencies/stock, paying dividends, creating asset accounts, sending/receiving digital cash, writing/depositing cheques, cashier's cheques, creating basket currencies, trading on markets, scripting custom agreements, recurring payments, escrow, etc. Open-Transactions uses strong crypto. The balances are unchangeable (even by a malicious server.) The receipt history is destructible. The transactions are unforgeable. The cash is unlinkable. The cheques are non-repudiable. Etc.
This commit adds a Go SWIG wrapper, and adds the autoconf option "--with-go" to build libotapi-go.so.
For a Go package to use this wrapper, it would use this import line
include "github.com/FellowTraveler/Open-Transactions/swig/glue/go"
The wrapper is a total mess from the Go perspective, so a reasonable package would import otapi then wrap the SWIG code into idiomatic Go. That means the end user would probably import a third-party Go package that imports otapi internally, and would simply have to ensure that libotapi-go.so was present.
It's possible that the SWIG wrappers may change at git HEAD and there would be a symbol mismatch between a local libotap-go and the wrapper, but that is really due to an oversight in the way Go fetches and stores libraries.
This commit adds a Go SWIG wrapper, and adds the autoconf option "--with-go" to build libotapi-go.so.
For a Go package to use this wrapper, it would use this import line
The wrapper is a total mess from the Go perspective, so a reasonable package would import otapi then wrap the SWIG code into idiomatic Go. That means the end user would probably import a third-party Go package that imports otapi internally, and would simply have to ensure that libotapi-go.so was present.
It's possible that the SWIG wrappers may change at git HEAD and there would be a symbol mismatch between a local libotap-go and the wrapper, but that is really due to an oversight in the way Go fetches and stores libraries.