Flatten GetResponse/SubscribeResponse #62
Conversation
remingtonc
requested review from
a team,
brh55,
skkumaravel and
miott
and removed request for
a team
There was a problem hiding this comment.
Can you think of any general way to make this conversion so it is not message type specific? Since you can specify any message structure you want in a proto file and compile it, this could be never-ending. I have now seen 3 gRPC type proto's that Cisco supports and the latest "gNOI" is the perfect example of, basically, endless custom proto's. Seems like "MessageToJson" is exactly that type of general parser. Might be better to dig into that library function and subclass or enhance it.
| raise Exception("Unhandled element type!") | ||
| key_string = "" | ||
| for key, value in keys.items(): | ||
| key_string += "[{key}={value}]".format(key=key, value=value) |
There was a problem hiding this comment.
Values to keys may have illegal url characters so you should put them in quotes (I think that is good enough)
"[{key}=\"{value}\"]"
| for elem in path.elem: | ||
| xpath += "/{}".format(elem.name) | ||
| for key in elem.key: | ||
| xpath += "[{}={}]".format(key, elem.key[key]) |
|
Good callouts @miott. The main point here is purely to flatten the data itself within the |
|
I have some decode functions in the gnmi class I use to talk to your library. After going through that, I then saw gRPC MDT protobufs and was introduced to gNOI protobufs. That is what got me trying to think broader on this subject. I would like to try figuring out what the services are and the expected input/output in a general infrastructure by parsing the protobuf files rather than coming up with a new test tool every time someone creates a new protobuf. Just thinking out loud. |
|
Moving this functionality to a separate library. |
Responses to Get and Subscribe can be deeply nested, this will provide a flattened view.
e.g.
Fixes #60