Open Hadatko opened 1 month ago
In the other hand, it makes the erpcgen more complex for things that the user can implement for himself. But I understand that validation is critical for RPC security. I think such thing would be better if will be somehow in different code validation layer to not mix with the rpc layer.
Another 'problem' is that when RPC protocol working OK and just validation fai, I would expect some error to return to sender, but erpc not have error return code when something failes (maybe that is somethin we need to add, it is really not convinient)
Well it is something user need to define to propagate this feature into generated code. I would like to keep it simple and do not create any new abstraction layer. For validation fail we can simply return new error status code.
I am not totally against, just want to carify my points. The cons in not adding new layer is that current layer code development will be harder (I understand that for user it isOK) The cons with returning erpc error is that it causes server to return error to current error, not returning anything to user (that will probably wait forever or get to timeout)
Is your feature request related to a problem? Please describe
Currently i am working on project where eRPC would fit but it is missing parameters configuration like: e.g. number could have @maxValue, @minValue, @regexValidation,.... This way user may benefit to generate code which he would need write manually...
Describe the solution you'd like
Add more annotations to customize parameter possible values
Describe alternatives you've considered
I need write another generator for this
Steps you didn't forgot to do
Additional context