grpc-labview
grpc-labview copied to clipboard
ni
Take Message Names from Message Cluster Typedefs
Your examples define the name of Message types in multiple places. Consider always using the Cluster typedef name to get the name. So, for example, when one registers a gRPC message, input the actual message clusters and use the typedef name (also this allows combining registration of message type names with the registration of gRPC messages themselves, simplifying the API).
Not really <scope: examples>, as I mean changing how you register messages and procedures so the initialization code looks like this (where teh User is just connection Clusters to define the Request and Response types):
I'm seeing this with several of your reports. They seem to be solutions but the problem is not always clear. Our intended workflow is to start with a proto file and generate the client code. Isn't all the code you describe generated in this case? If so, then this seems invisible to end users and at most it is tech debt that simplifies the generated code.
What is the end user workflow where this is important? If there is workflow that you think is underserved, then that should be the issue. This allows us to priorities based on the workflow and consider all solutions that might improve that workflow.
You are right, I shall make a "workflow" issue, as I think that is by far the biggest issue, that you are in danger of producing a gRPC solution that will not be widely adopted.
...generate the client code. Isn't all the code you describe generated in this case?
BTW, I show code for a Server, not a Client. This is defining the Procedures implemented by a gRPC Server.
My n=1 is that the typedef suggested here is much more obvious when browsing through the code to understand both the local details and the big picture.
