You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The simplest result messages contain a result code and/or a string. Optionally, there could be more.
It would be ideal if these could be retrieved from a response message in a generic manner. Especially when passing requests to a server, it is useful to be able to learn easily what it has said.
Similarly, the ability to build such responses through generic support is welcome, because many commands do not require additional data anyway.
The text was updated successfully, but these errors were encountered:
One way of doing this is by side-channeling responses to lillyget_response() and lillyput_response(). This would simplify both processing responses and generating them, just as planned above. Moreover, it would integrate nicely with the API above.
The question that remains is when to invoke lillyget_operation() with a more-than-average result. This may be the decision of the configuration, and could possibly be made specifically for an operation code. Whether lillyput_operation() or lillyput_response() is used is a much easier choice; the application simply does what it likes.
We should put some thought into the ordering of the API calls, for sure, but it does seem to make sense to add response handling with a possibly different treatment.
The simplest result messages contain a result code and/or a string. Optionally, there could be more.
It would be ideal if these could be retrieved from a response message in a generic manner. Especially when passing requests to a server, it is useful to be able to learn easily what it has said.
Similarly, the ability to build such responses through generic support is welcome, because many commands do not require additional data anyway.
The text was updated successfully, but these errors were encountered: