-
Notifications
You must be signed in to change notification settings - Fork 277
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
Split tokens into a separate crate #4214
Comments
so in essence we can define |
I also think that would be the best approach. Just the last note I have in mind. |
I have a concern about swappable data model in general. Currently, probably the main reason to use an SDK is to safely build data model types. If data model is not static, then Iroha users (other devs) will have to build their own SDKs, which seems like a huge overhead. Not entirely sure if my concern is 100% related to this issue. |
Yes, your concern is related and valid |
Regarding SDK problem I think we should provide support for default types as we do now. But if users will decide that they need some kind of expressions or anything else they should be able to combine our SDK and their own data model |
closed as part of #4791 |
We should explore ways how to move
smart_contract/default/tokens.rs
into a separate crate that can be imported by bothiroha_executor
andiroha_client
. The big problem to consider here is how to have that crate swappable because we want, not just default tokens, but also user defined tokens to be provided by this crate.The solution we find for tokens will be a foundation for creating
executor_data_model
crate which will contain all structures that are shared byiroha_executor
andiroha_client
such as custom expression system.I somehow don't feel this is possible to do. I think that every executor will define it's own
executor_data_model
crate which will then be imported by the client. When a user creates their ownexecutor
, they will also make their ownexecutor_data_model
which can (but doesn't have to) re-exportiroha_default_executor_data_model
The text was updated successfully, but these errors were encountered: