RPC specific executions

[jgroom33]

Libraries typically support the most common RPC's:

• edit-config
• get

This allows a simplified payload for the most commonly executed RPC's.

This plugin should provide the same.

Implementation options:

Option 1. Auto-discovery (enabled/disabled with a boolean in settings)

• check for <config> as the root and assume an edit-config. Use a configured default for target/default-operation
• check for <edit-config> as the root and assume an edit-config. use the specified target/default-operation
• check for <filter> as the root and assume <get>

Option 2. Right click on the "Send" button to select the desired RPC for the payload

Option 3. ??

[wisotzky]

@jgroom33, it would be great to understand your target use-case. What is the kind of user that would use the new functionality? Why would he/she prefer to do it this way compared to the available options the extension provides today?

As discussed in the open feature-requests, the extension right now is not YANG-aware. In conclusion things like XML auto-complete, conversion between XML/JSON/YAML, XML validation/linter or intelli-sense are not applicable.

My understanding of your ask:

• Ability to execute an edit-config without providing the corresponding headers (rpc/edit-config). The corresponding TextEditor would only need to hold the payload (device model instance).
• The target datastore would be automatically be selected based on the capability exchange. If candidate datastore is used if supported. Writeable running is used as fallback.
• Default-operation "merge" to be used. Users might override the option for specific subtrees.

It's worth to remind, that this solution would be specific to the original rfc6241 definition. New RPC like NMDA-compliant get/set data would not be supported.

As XML documents need to have a single root element, approach would not work when editing elements in multiple root-level trees.

[jgroom33]

@wisotzky The use case I'm thinking of:

1. User has a collection of xml files that are used by other toolchains (ansible, python, etc)
2. xml file contents do not always contain the full RPC

• root is <filter>
• root is <config>
• root is <edit-config>

3. This plugin operates in one of two ways:
   1. attempt to auto-determine the rpc
   2. right-click action on the Send button to choose the rpc

[wisotzky]

Adding missing headers could be possible.
The following logic can be assumed:

IF root is <rpc> THEN
send XMLDOC
ELSE IF root is <config> THEN
send ...XMLDOC
ELSE IF root is <filter> THEN
send __XMLDOC
ELSE
send XMLDOC

For the edit case, people might want a full blown transaction flow of:
lock > edit-config > validate > commit > confirm > unlock

Default/edit operation for edit-config might be for debate.

A filter could also be valuable for get-config (not just get) - so might need to prompt the user.

There might be no extra control of the target datastore (running vs candidate) - or need to prompt the user.

Finally, NMDA would not be considered (operational datastore, set-data, get-data, ...)

[jgroom33]

The proposed logic seems appropriate.

Maybe the implementation could be generic and allow the user to decide on the wrapper. i.e. a settings prop like this:

[
 { "match": "config",
    "wrapper": "<edit-config>{{ payload }}</edit-config>",
    "rpc": "edit-config"
 },
 { "match": "filter",
    "wrapper": "<get>{{ payload }}</get>",
    "rpc": "get"
 }
]

This concept could be extended to handle a series of calls in the case of a desired workflow: lock > edit-config > validate > commit > confirm > unlock

[wisotzky]

So I guess you are saying, that it would become the user being responsible to define "macros". The decision would be based on the root-level node... The advanced ask would be, to allow people even to do a multi-request macro. Would need to look into the details, what that actually implies.

[jgroom33]

The macros are interesting, but that is probably better as a separate feature.

For now, it's probably better to focus on the simplified use case.
as you detailed:

IF root is <rpc> THEN
send XMLDOC
ELSE IF root is <config> THEN
send ...XMLDOC
ELSE IF root is <filter> THEN
send __XMLDOC
ELSE
send XMLDOC

For a simplified implementation that focuses on RPC wrapper helpers, the "wrapper" could be a setting for the user.

let's assume the following setting for the plugin:

{
  "vscode-netconf": {
    "wrappers": [
      { 
          "keyMatch": "filter",
          "wrapper": "<rpc><get-config>{{ payload }} <get-config><rpc>"
      }
    ]
  }
}

The user could specify as list of match/wrappers that would be evaluated during execution.