Closed ondrej-fabry closed 2 years ago
Agreed, solution 3 seems to be ideal among the three.
The only drawback I can see is that it adds an extra return value and most users won't need it,
but it's easy to ignore. Also that way it becomes a natural extension of RecvMsg()
Intro
There are two types of dump requests in VPP API:
Below is a code sample of generated code for
Recv()
method of RPC client for dumping output interfaces innat44_ed
VPP API:https://github.com/FDio/govpp/blob/f77cad358519c63ce5a184765726fbb79b6f9be5/binapi/nat44_ed/nat44_ed_rpc.ba.go#L233-L250
Current problems
The generated code for the RPC client for Dump+Reply requests does not provide access to the
*Reply
message that is received as last message. This practically makes the generated code unusable for users that need the*Reply
message values, e.g. reply message often contains aCursor
field where its value is used in the next request.Another problem is that the
Retval
field from the*Reply
is not converted to error.Possible solutions
There are at least three alternative solutions that could be implemented to fix this.
1. SOLUTION
Add another method
RecvReply()
to dump clientWhen calling
Recv()
and receivingio.EOF
error, the actual*Reply
message received would be stored to a field of dump client and user would callRecvReply()
(placeholder name) to receive it.CONS:
io.EOF
2. SOLUTION
Define union-like type and return it instead of
*Details
When calling
Recv()
and receivingio.EOF
error, the return value would only have*Reply
message set otherwise only*Details
message would be set.CONS:
3. SOLUTION
Return 3 values from
Recv()
When calling
Recv()
and receivingio.EOF
error, the actual*Reply
message received would be returned as second return value, otherwise only*Details
orerror
would be non-nil.CONS:
I am personally for solution 3 as I do not see any disadvantages for it.
CC @edwarnicke @sknat