-
Notifications
You must be signed in to change notification settings - Fork 517
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
Full custom definition support #2692
Comments
One other thought: we could potentially shrink the binary codec significantly with the complete removal of the definitions.json file entirely, relying entirely on the |
@mvadari Yes, I agree with you. Regarding removing the I suspect the initial latency might be high (due to fetching the Are there any other concerns? I believe there are many rippled servers that provide a public-API |
The issue with this is that in this repo we have models and validation. So we could use the binary codec and not use the transaction model however i think this results in errors when signing so you end up doing a lot of Also requests sorta break this from a sidechain issue as we also have requests and objects that need to be parsed specifically for that chain. If you really wanted to make this an agnostic repo, exporting the transactions, with their required/optional values could help you build a custom model but I dont think typescript can do this runtime, but maybe an automated github task to create different models for different sidechains. I actually tree shook the models here if you're interested in what that would look like. We can actually use these models in the |
If you're strictly only using the binary codec you should be fine, because the binary codec doesn't use those models. If that's not true, then that's a (minor) bug.
We can't solve all the problems, lol. But maybe that can be mostly resolved via
There's been some previous discussion about tree-shaking (see #2307 for example), but I think it hasn't been high priority so far. |
Definitions support for |
It'd be much easier to use the same library with different sidechains that support different features, since it affects serialization and signing capabilities.
Some work already done on this front:
definitions.json
values at runtime via encode/decode parameter #2127The only remaining step is to add support for the
server_definitions
RPC method - to call it on connection and store/use it if it is different than the stored file.The text was updated successfully, but these errors were encountered: