Cannot build a rpc-reply element without <data/> element

[ntadas]

Currently libnetconf allows to send rpc replies with

• element
• elements
• element

But there is no support for custom elements. Assuming we have defined a user rpc like this:

  rpc activate-software-image {
         input {
             leaf image-name {
                 type string;
             }
         }
         output {
             leaf status {
                 type string;
             }
         }

     }

The expected output would be something like this:

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <status xmlns="http://acme.example.com/system">
         The image acmefw-2.3 is being installed.
       </status>
     </rpc-reply>

But currently, using libnetconf the only reply we can generate would be (using nc_reply_data):

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <data>
              <status xmlns="http://acme.example.com/system">
                      The image acmefw-2.3 is being installed.
              </status>
          </data>
     </rpc-reply>

And this output fails the data model validation as there is no ‘data’ element defined in the model.

Would it be possible to have a similar function “nc_reply_custom_data”, which would behave exactly as nc_reply_data, but would not add the element (messages.c without 1891 to 1901)?

Thanks in advance

[michalvasko]

Hi, please verify that it works as expected, thanks.

Regards, Michal

[ntadas]

Hi Michal,

first thanks for the quick fix but I still see 2 problems (it seems that the fix is not as easy as it looked):

1- the netopeer-cli is using the nc_reply_get_data to process user-rpc replies so it fails because it doesn't find the data node in the reply

2- it is not possible to send a list as a output of the user rpc, we can send a leaf but if we try to use a list the method xmlReadMemory fill fail (its expecting a single xml node as root, see messages.c line 1895).

Best Regards

[michalvasko]

Hi, this is no longer a quick fix, so we will not spend more time on it, I am sorry. This is the same issue as #222.

Regards, Michal

[mrmouro]

Hi Michal,

I'm working on a fix for this issue but I would like to tailor the fix to your requirements so the pull request is accepted, as it is important for us to maintain the library pristine and avoid patches in our build.

I'm able to build rpc replies with custom data (no data element in rpc-reply), but I need to adapt also the nc_reply_get_data method to retrieve information from a rpc-reply with custom data.

For this I see two options: 1- Add a new NC_REPLY_TYPE called _NC_REPLY_DATACUSTOM that will be handled in nc_reply_parse_type. The nc_reply_custom would create rpc-replies of NC_REPLY_TYPE NC_REPLY_DATA_CUSTOM. 2- Or for custom messages continue to use NC_REPLY_DATA and adapt current methods to cope with both kind of data replies.

Option 1 has the benefit of less intrusive changes. All the current methods would remain untouched, and we would have to implement new ones for the new reply type : for example _nc_reply_get_datacustom to be used in netopeer-cli .

Option 2 is quicker and dirtier and wouldn't require any changes to netopeer-cli, but the changes to nc_reply_get_data will leave this method less robust as we wouldn't be checking for a data element.

Your feedback is welcome. best regards

joao

[michalvasko]

Hi Joao, option 1 seems like the better choice, but deciding whether to use nc_reply_get_data() or nc_reply_get_data_custom() in cli is not trivial. So I suggest you go for option 2 with some minor changes. Keep using NC_REPLY_DATA for the reply, but add the function nc_reply_get_data_custom(), which will simply skip checking what the top-element in the reply is and returns the data with it. We can then sue this function in the cli, but the previous function will remain for anyone happily using it.

Regards, Michal

[mrmouro]

Hi Michal, thanks for your fast reply. I've made the necessary changes.

If we had choosen to go with option 1), the decision to use _nc_reply_getdata or _nc_reply_get_datacustom in cli would merely depend on the outcome of the reply type (NC_REPLY_DATA vs N_REPLY_DATA_CUSTOM), as _nc_reply_parsetype would return the correct reply type.

I've made a couple of tests to the proposed changes and they work for both cases: 1) custom rpc_reply with single node 2) custom rpc_reply with list of nodes

Of course this will require some adaptation to netopeer-cli.

Best regards Joao