-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openRPC based APIs #2346
Comments
to have openrpc for zos api we need some modification to myceilum for user verification so it would be better if the user starts myceilum with his mnemonics so it has the same identity on the chain and from that we can check the sender ip and using myceilum we can get the key hence we can look up his twin with that key from the chain so we verify that it is the same user. so what needed from myceilum |
so far I checked those pkgs 2- https://github.com/gregdhill/go-openrpc p.s all the above pkgs doesn't provide client code generation, so whatever we will choose from the above we will relay on an external openrpc client generation tool |
Update: to simplify things here is what we need:
as an implementation, i am thinking of:
another quicker approach @ashraffouda suggests is to start from the doc file itself so
Suggestion
both suggestions will take some time, so to finish things quickly we could go with ashraf suggestion and then consider one of the suggestions. |
it will be better if we can build the server then generate the spec file out of it, but as u mentioned this is not well supported in golang, but to do this by either create a tool to generate this file or modify one of the existing libs to do this will take much time than expected, my suggestion is to create the spec file manually and use gregdhill/go-openrpc to create server code which I think will be much much faster than doing other suggestions |
work is done on the:
waiting for this threefoldtech/mycelium#341 |
blocked on threefoldtech/mycelium#341 |
the plan would be exposing zos APIs over mycelium IP, Let's start by creating openRPC documentation, underlying handlers won't need to be changed
KDS is suggesting documenting using this https://pypi.org/project/tabella/
The text was updated successfully, but these errors were encountered: