Currently there are many code/implementation assumptions related to the de/serialization of the args and the return type. Only json is available and there is no way to change it.
Before having an additional configuration for it, such as adding borsh, one possibility is to try making no assumptions at all about what kind of de/serialization will be used, besides that it will be related to Args and Return structures with named fields, and that they must be able convert into/from bytes.
It may be possible to require all structural attributes to be explicitly declared by the user, such that each attribute (eg. #[derive(Deserialize)] must be passed in from attributes on the methods.
With this, many other configurations would be potentially allowed. Then after that, some helper attributes can be created to make common configurations implicit, such as attaching an attribute related to json on a single top-item.
Currently there are many code/implementation assumptions related to the de/serialization of the args and the return type. Only json is available and there is no way to change it.
Before having an additional configuration for it, such as adding borsh, one possibility is to try making no assumptions at all about what kind of de/serialization will be used, besides that it will be related to
ArgsandReturnstructures with named fields, and that they must be able convert into/from bytes.It may be possible to require all structural attributes to be explicitly declared by the user, such that each attribute (eg.
#[derive(Deserialize)] must be passed in from attributes on the methods.With this, many other configurations would be potentially allowed. Then after that, some helper attributes can be created to make common configurations implicit, such as attaching an attribute related to
jsonon a single top-item.