Improvements

[jgroom33]

Thank you for making a useful tool.

Please consider these suggestions for improvement:

1. Use an icon on the left side bar
2. The sidebar would display:
   a. dropdown for device selection
   b. common rpcs (edit, get)

[wisotzky]

Hi Jeff (@jgroom33),

could you refer to an extension as a reference using the sidebar?
So far, I've preferred the abuse of the statusbar, because I typically have the Explorer View open in the sidebar.
Changing between views in the sidebar is typically slowing down my efficiency.

[jgroom33]

I've had a difficult time getting into the workflow of this plugin. That's what prompted the suggestions.

Perhaps using the sidebar is not the best implementation, so here are some general things that I think would improve the plugin:

1. Don't require settings update to add devices
2. allow simplified execution of "common" execution types (raw rpc, get-config, set-config, filter)

Specifying the entire payload for all executions is too verbose. There should be a way the choose the rpc and the file would only contain the payload for that rpc type.

This is an interesting plugin and might have some ideas:
https://marketplace.visualstudio.com/items?itemName=humao.rest-client

An example xml execution file could look something like this:

<!-- 
rpc: get
host: 10.10.10.10
port: 830
username: admin
password: admin
-->
<filter type="subtree">
  <system xmlns="http://openconfig.net/yang/system">
    <config>
      <location xmlns="http://www.ciena.com/ns/yang/ciena-system" />
    </config>
  </system>
</filter>

In the above example, the comments would be parsed and implemented for connection and execution.

The other option is to implement something in the UI that provides similar behavior.

[wisotzky]

Morning @jgroom33,
I do admit that the usage of the statusbar is rather specific to this extension, while it potentially feels not intuitive at the first sight for vscode power users.
For me the main usage of the tool is to help people to learn about the mechanics of NETCONF and potentially the specifics of certain vendor implementations. It allows to try/capture valid XML requests and responses to enable templating for intent-based solution.
The tool itself is designed to allow users to control, when the NETCONF connection is established and disconnected. In conclusion embedding connection details as comment is somewhat contradicting the main idea of keeping the connection alive.
Rational, why we keep the connection open:

• It allows to receive NETCONF notification from the NETCONF server
• Overall performance is better
• It is required to work with candidates, as certain workflows require multiple request to be send via the same NETCONF session. Example: lock>edit>validate>commit>unlock

I can see good rational to simplify the process of managing NETCONF servers (add, modify, remove), without forcing people to manipulate the extension settings.

I can look into providing more shortcuts (potentially also snippets to speed up coding).

[jgroom33]

@wisotzky I agree the goal of connection management is good.
Here are a couple more ideas:

1. The device props (name/ip/login/etc) can be stored in some type of inventory file. Using ansible's inventory.yml format could be beneficial. There's an AWS credential selector plugin that uses this implementation in the status bar.
2. Consider using the debug architecture. Here's a screen shot of how that might look. This implementation would still require the inventory selection, but provides a different execution action.