-
Notifications
You must be signed in to change notification settings - Fork 80
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
RPC client refactoring plan #2597
Comments
I think
We already have something similar in However, it would be nice to have |
We're at 4-6 at the moment, 4 is not yet completed (notary, nns, tokeninfo), yet at the same time we already have a nice contract coverage for 6 and at least partially established APIs for 5 (Method (that sends transaction), MethodTransaction (signs, but not sends), MethodUnsigned (not signed transaction returned)). And yet we have 8 done for reader calls. |
We're done up to number 6 now. We don't have a wrapper for StdLib or CryptoLib contracts, but I doubt these wrappers can be useful, these contracts are just libraries to be used by other contracts. We also don't have one for the Ledger contract, but all of what it does is accessible via regular RPC API, no point in wrapping it. All the other contracts are completely available. As for 7. We have the concept of We also have full historic abilities in So we can move on to canonical wait loops of 9 and then a separate issue for 10. |
#2585 and #2586 solved the problem of excessive client dependencies, now we can move on to other topics. We already have #1967, but that's not the only problem we have, even though it sets the main direction of RPC client evolution. But we have other problems as well:
Unfortunately,
client
andserver
are not a very good package names. We also have data types split betweenrequest
,response
andresponse/result
. All of this was done quite a long time ago and can be improved to simplify using the client. But it's controversial at the same time, because it's a breaking change.While it's very natural for the RPC protocol we have is not very usable without an ability to convert convert from/to regular Go types (like toStackParameter in NeoFS).
Explained in Wrap contracts into another structure in RPC client #1967, we have both simple API requests there as well as higher-order functions like
NEP17Symbol
orMultiTransferNEP17
.While NEP-17 functions are present, one can't easily do
vote
in NEO contract, for example.Backend code mostly wants to work with some particular contract and while it can implement NEP-17 or other standard it's also very likely to have some task-specific methods that aren't easily accessible currently.
State-changing requests normally produce a transaction and the client then needs to wait for the result. While the best way to do that is via subscriptions, it can also do polling and currently it's out of client's scope.
ValidUntilBlock
.Which means that the client doesn't know how long to wait for the transaction to be accepted (or not).
There has to be some uniformity there, proper client needs both.
Any state-changing method should be available for test execution as well as creation of a complete transaction and its transmission.
Again, any method can be invoked with some old state and this should be possible to do easily without moving a layer below (calling generic
InvokeFunctionAtHeight
or similar).What I'd like to do is to concentrate first on the functionality we have, not expanding it in the first phase. At the same time breaking changes are better be done eariler, therefore the plan that I have in mind is:
rpc/client
torpc/rpcclient
,rpc/server
torpc/rpcserver
and mergerequest
/response
/result
intoneojson
package. So it'll be likeneojson.Request
,neojson.Response
,neojson.Invocation
. I'm interested in opinions on this though.smartcontract
package. It's there exactly for this purpose.nep17
where possible. This will affect all clients, unfortunately. I'd like to keep old APIs available for at least one release along with the new ones, but I'm not sure it'll be possible to do this due to potential package import cycles.Either a set of new methods (
nep17.Transfer
vsnep17.TestTransfer
) or some interface implementation (nep17.Transfer
but with modified underlying client or setting). But it's likely to be the first one as test executions provide a lot of additional data that might be useful for the client in various circumstances.Via an interfaced lower-layer client that will be initialized with some state definition, like
Unfortunately, there will be a lot of breaking changes, so I'm interested in opinions on how can we make this transition period less stressful for people. And in general, what can we do more or less.
The text was updated successfully, but these errors were encountered: