While working with an internal netconf service I discovered that OKResp and other structs were not being parsed properly. This is because xml (and thus encoding/xml) is document focused. An XML document has single root. This means the "defered" parsing of the <rpc-reply> body doesn't work as you need a proper root node (not just a value) as well you cannot support multiple nodes.
To fix this, begrudgingly, this change changes the API to to not just expose the Body to the call but the entire <rpc-reply> to be parsed. The same goes for <notification>.
This could mean slightly larger allocations, but really.... it doesn't matter. The majority of the data would be inside the Body value anyway so adding the wrapping <rpc-reply> doesn't add much.
I think there is room in a v2 to explore a full stream based solution here, but not needed for this. It does make the full io.Reader/io.Writer of RFC6242 kinda.. worthless now, but perhaps this will make things like netconf over QUIC possible. We will see.
Closes: #62
Breaking changes
Reply.Body and Notification.Body are now gone. In their place there is a Raw() and String() methods on both structs to return the raw data and a string representation.
OkResp was renamed to OKReply
GetConfigReply was reworked to assume as the base.
I think there is future work to make a <rpc-reply> drop in for structs to enforce the root node, but this works for now.
While working with an internal netconf service I discovered that OKResp and other structs were not being parsed properly. This is because xml (and thus
encoding/xml) is document focused. An XML document has single root. This means the "defered" parsing of the<rpc-reply>body doesn't work as you need a proper root node (not just a value) as well you cannot support multiple nodes.To fix this, begrudgingly, this change changes the API to to not just expose the
Bodyto the call but the entire<rpc-reply>to be parsed. The same goes for<notification>.This could mean slightly larger allocations, but really.... it doesn't matter. The majority of the data would be inside the
Bodyvalue anyway so adding the wrapping<rpc-reply>doesn't add much.I think there is room in a v2 to explore a full stream based solution here, but not needed for this. It does make the full io.Reader/io.Writer of RFC6242 kinda.. worthless now, but perhaps this will make things like netconf over QUIC possible. We will see.
Closes: #62
Breaking changes
Raw()andString()methods on both structs to return the raw data and a string representation.I think there is future work to make a
<rpc-reply>drop in for structs to enforce the root node, but this works for now.