Configuration options for external programs (protocols and tools)

[VShawn]

In order to achieve new requirements #59, we need a system that that can config external programs. like mRemoteNG did:

The difference between this system and mRemoteNG is that we need to implement two sets of external program manager.

1. Protocol Program Manager: It can only specify external programs for specific protocol settings. For example, ssh can only set the KiTTY path, and FTP can only set the WinSCP path.

2. Third-party external program manager: It has basically the same as mRemoteNG did, you can set all exe as external programs, configure their paths, transfer parameters, etc.

In fact, in my opinion, the above scheme does not look very flexible, and I am still considering other implementations.

[majkinetor]

Let me brainstorm about this a little:

Tool configuration

1. Specify arbitrary path to arbitrary executable. Full path should be optional, $Env:PATH is used. Env vars in path should be supported.
2. Map config settings to local environment variables, such as %HOSTNAME%, %USERNAME% etc. that can be used when specifying command line arguments to a tool.
3. ComboBox to specify type of supported provider (RDP, FTP...).

Some CLI tools might even need specifying stdin.

Notes

Cli tools

CLI tools use different Windows subsystem but could probably be treated equally as GUI tools by invoking them via cmd.exe internally.

Custom providers

Not sure if adding arbitrary providers should be allowed (tool abc.exe handles abc connection type). Multiple tools could theoretically handle the same provider (eg. WinScp or FileZIlla).

So RDP currently has several extra options (mapping of remote resources and display options) and SSH has Advantage and key options. In essence, if tool supports setting those via command line parameters then this is about mapping New remote config on tool CLI parameter . This then calls to defining properties on tools configuration that will be exposed in New remote UI.

Lets see on KITTY example and what we currently have in PRM:

• Name, Group, Address, user, password, port - PRM should have those on ALL providers as absolute minimum.
• Private key, SSH version, Auto command: those are specific to protocol and could come from tool configuration and mapping to CLI options must be provided:
  • -cmd maps to Auto command
  • -i maps to Private key
  • -1 and -2 map to SSH version

So lets imagine we have Protocol Definition UI that could used to define mapping:

| Protocol Definition               |
|===============================
| Protocol Name: [> SSH ]    [+]
|-------------------------------
| Auto command
|   Type: string
|---
| Private key
|   Type: file
|---
| SSH Version
|   Type: radio
|   Mandatory: true
|   Values: V1, *V2
|---
| External Configuration
|    Type: file
|---
| Run agent
|    Type: boolean

NOTE:

• Configuration env var is automatically named by joining title using underscore, no need to specify it
• Types could be string, number, file, radio, combo, boolean
  • Its there just for GUI rendering, however, it could basically be simplified to string always
  • It defaults to string
• * above specifies that value is default.

Having this separated from tools configuration, we can then map tools to protocols in tool configuration which will allow you to map multiple tool options to single interface.

So lets now define kitty tool options once we defined SSH protocol (ofc, this one would come predefined):

| Tool configuration: kitty
|================================================================
| Protocol: [> SSH]
| ...
| ...
| Protocol options
| ----
|   Auto command: [ -cmd '%AUTO_COMMAND%' ]
|   Private key: [ -i '%PRIVATE_KEY%' ]
|   SSH Version: 
|       V1:  [ -1 ]
|       V2:  [ -2 ]
|   External Configuration: [ -kload '%EXTERNAL_CONFIGURATION%' ]

Now, I'll just leave this here to incubate, I am not sure if this is ultra flexible or complicates things without great benefit. On the other hand, it looks like implementation is pretty easy (probably day's work).

Not sure at this moment how this could work on RDP as those options are probably library options (didn't look into source code yet, just assuming), but I guess PRM could actually crate tiny exe wrappers (If I remember correctly this is what you do now) and along with that expose everything desired as CLA.

[VShawn]

I though of this
I think it would be quite troublesome to allow users to define their own protocols. Few people want to learn this complex definitions. And it does not match the positioning of the product (a simple tiny personal). Why not we pre-define what protocols we can provide, user can select tool they like to connect a protocol, or use a preset tool we offered for a quick use.

E.g. SSH

We offering PuTTY as default terminal. Some users may want to use something named XuTTY.

• For normal user they can open new issue to ask us add XuTTY into official SSH support list.
• For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS.

This is less flexible, but simpler.

[majkinetor]

I think it would be quite troublesome to allow users to define their own protocols

That depends on UX. It could be there as advanced option that can be used internally mostly or by advanced users that know what to do.

For normal user they can open new issue to ask us add XuTTY into official SSH support list.

You understand that this is basically unlimited feature request potential (there are so many tools) ? With the feature offered, you can always say to users please try to configure it on your own and just provide us config that you are happy with so we can copy/paste it into the project to be supported officially. You don't block such users if they are willing enough, and you can immediately use all their successful work.

For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS.

Yeah, they can if they have this protocol to cmd line map feature. How would they do it without it ? How do you know what of number options such tools have to expose in PRM config ? Just take putty as an example. You exposed few options only.

[majkinetor]

I will close this since most of it is released in v0.6.

[majkinetor]

Third-party external program isn't part of 0.6 release, but it could be handled via another ticket if needed. The benefit is IMO very small compared to random launcher in Windows (you could pass details of 'current connection' as parameters of external tools).