Custom protocol redesign

[majkinetor]

Currently, we have custom protocols that can be defined per connection category. Also, we have App connection type which is almost exactly the same as protocol.

details

Protocols:

App:

I don't think this is good for two reasons:

There is no particular distinction between protocol and app:

1. Both are CLI programs driven by arguments and environment vars
2. Protocols are now artificially tied to categories, there is no need for that, it's not intuitive and is even misleading (FreeRDP in VNC category as one example)
3. There is currently no way to provide additional protocol settings, which is needed almost all the time
4. We can simplify interface by treating them the same

The main idea

Remove protocols and make App better.

Option 1

Easy option: remove protocols completely without adding anything new except small changes to App "connection":

Regarding this option:

1. HOSTNAME, PORT, USERNAME and PASSWORD (HPUP) must be added via command line
   1. Not a great user interface but passable. We could make CMD parameter a bit more user-friendly - multiline, wrapped, so it's easy to see the entire thing without scrolling or using Preview. There is no functionality lost here.
2. Availability detection is lost
   1. Unless we show HPUP fields in Apps too and pass them via environment vars as with other connections
   2. People may ignore them if they do not need them
   3. if HOSTNAME is set, we can run availability detection again
3. Alternatives are lost in its current form
   1. Again, unless we show HPUP fields
   2. ... but can be returned even without them via a set of alternative CMD lines

In summary, this is easy to achieve and will make app less complex. To implement:

1. Remove protocols from configuration and Select runner from each connection type
2. In the App "connection"
   1. Add HPUP, availability detection and Alternatives
   2. Add environment vars section (otherwise the feature is lost)
   3. Make Cmd Parameter multiline and wrapped (one is expected to manually map HPUP environment vars that 1RM creates the same as before)

Option 2

Complex option: Predefine some applications, similar to what we have now with protocols:

1. Remove protocols UI in configuration completely
2. Add Apps tab in configuration similar to protocols but without connection categories
   1. Allow user to define array of apps
3. In App "connection"
   1. Add Select App with defined apps and remove Select Runner from other connection types
   2. Present mandatory parameters as input elements, so protocols can have HPUP as before
   3. 1RM will pass mandatory parameters as env vars, the same as before
   4. 1RM currently keeps protocol definition as JSON, we can extend it to support additional stuff

Details

Definition

1. name [string, mandatory]
   1. Mandatory user supplied name of the tool
2. cmd [string, mandatory]
   1. Command line arguments
3. path [string, optional]
   1. Path list where tool will be searched for, in addition to the $Env:PATH which is always included
4. environment [string, optional]
   1. List of user provided environment vars, one per line in the form ENV=VALUE
5. hosting [bool, default: true]
   1. True if tool is to be hosted
6. elevated [bool, default: false]
   1. True if tool is to be run with admin credentials
   2. NOTE: If multiple elevated tools are run at the same time, it would be good to ask for elevation only once or to cache elevation response for some time.
7. helpUrl [string, optional]
   1. URL of the help page of the tool
8. flags [array[object], optional]
   1. Detailed list of the tool flags that could be offered by 1RM as a list when creating connection
   2. Properties
      1. name [string, mandatory] - Name of the argument (and env. var that 1RM will use to pass value)
      2. format [string, mandatory] - Format of the CLI expression
      3. mandatory [bool] - Is this CLI parameter mandatory
      4. help [string] - Help tip
   3. NOTES:
      1. One can add HPUP here and mark them as mandatory in order for 1RM to show them.
      2. We could have those mandatory parameters shown as alternatives
      3. To get availability detection, we could have another bool on the flags, hostname: true

We could have extra fields in definition, such as Icon URL, flag type, name on multiple languages etc... all are trivial to add any time.

The purpose of this is to be able to share tools like now (and maybe even have a list of officially pre-added tools) and to make adding new App more user friendly instead of just having one Cmd Paramter field. Yes, its some work, although not much but makes it more professional and its IMO much better for end users because they will either get definition from the Internet or it will come included eventually with 1RM.

Example:

[
  {
    "name": "TigthVNC",
    "cmd" : "tvnviewer.exe",
    "path": "C:\\Program Files\\TightVNC; c:\\Program Files (86)\\TightVNC; c:\\Tools\\TightVNC",
    "helpUrl": "https://www.tightvnc.com/vncviewer.1.php",
    "env": "VNC_PASSWORD=%PASSWORD%",  //Assumes we have HPUP fields, if not, we can add env with hard coded password on App directly
    "hosting": true
  },
  {
    "name": "FreeRDP",
    "cmd": "wfreerdp.exe",
    "path": "C:\\Tools\\WFreeRDP",
    "hosting": true,
    "helpUrl": "https://github.com/awakecoding/FreeRDP-Manuals/blob/master/User/FreeRDP-User-Manual.markdown",
    "flags": [
        {
            "name": "Hostname",
            "format": "/v:%s",
            "mandatory": true
        },
        {
            "name": "Port",
            "format": "/port:%s",
            "mandatory": true,
            "default": "3389"    //We could have default, although in this case it doesn't have to be mandatory
        },
        {
            "name": "Username",
            "format": "/u:%s",
            "mandatory": true
        },
        {
            "name": "Password",
            "format": "/p:%s",
            "mandatory": true
        },
        {
            "name": "Audio mode",
            "format": "/audio-mode:%s",
            "help": "0 (local), 1 (remote)"
        },
        {
            "name": "Desktop Width",
            "format" "/w:%s"
        },
        {
            "name": "Desktop Height",
            "format" "/w:%s"
        },
        {
            "name": "Dynamic resolution",
            "format": "/dynamic-resolution"    // We could have type option in flag for bool|enum|number .... for even more user interface
        },
        {
            "name": "Drives",
            "format": "/drives",
            "help": "Set any value to see local drives remotelly"   //or just existence of field, even empty one counts as `true`
        },
        {
            "name": "Certificate Options",
            "format": "cert:%s",
            "help": "ignore, check ..."
        }
    ]
  }
]

New App

1. Add Select App with defined apps
   1. If not selected, we can use App as before, by manually specifying complete command line
2. Show Help link based on HelpUrl if it exists
3. For each mandatory flag create input UI element automatically
4. For non mandatory flags, create menu so one can add the flag via + button
5. Add alternatives for mandatory flags
6. Add extra environment vars (to be added in addition to those from definition)
7. NOTE: Cmd params are added in addition to to those provided in tool definition via cmd attribute

Mockup:

| App |

Name:
Tags:
Logo/color:

Script before/after:

Select app: [   FreeRdp  ]

Cmd line:   [ 
     /f  /admin 
]

Flags [+]
   Hostname:        [   ]
   Port:            [ 3389 ]
   Username:        [   ]  
   Password:        [   ] 
   
   Desktop Width:   [ 1200 ] x
   Desktop Height:  [ 800 ]  x

Alternative  [+]

Environment: [  
    
]

---

Links and related:

• Configuration options for external programs (protocols and tools) #61 (comment)
• Additional settings to connection using protocol #255
• Mutil-credential for other protocols #360
• Select protocol runner per connection #205

[majkinetor]

@VShawn, comments please :)

[VShawn]

Both options would disrupt the current intuitive logic of using protocols with runners(user set one connection, and choose which runner to use when start connection).

I would not choose option2:

1. Option 2 is incomplete as it fails to implement the associated options in your plan. For example, after setting dynamic resolution, the option to set a fixed resolution should be hidden.
2. Based on 1, it would require building a strong system to generates UI (WFP can achieve this, but it's not as convenient as HTML. I'm unsure about the effort required since I haven't tried it before, and it would obviously break the MVVM architecture).
3. The built-in RDP client, VNC client, and S/FTP client in 1RM cannot be launched using "cmd [string, mandatory]".
4. When modifying custom protocols, all connection configurations for the modified protocol need to be updated. For example, when renaming a field.
5. Based on 4, if we use a team database to store connection info of the custom protocols, we need to synchronize the custom protocol configuration files within the team and it may conflict

That's all I think of for now. The most critical is that the workload for option 2 is too large, and
I can't complete it quickly on my own. It would impact the release time for version 1.0. I suggest considering this option again after trying out web UI in the future.

Option 1 seems ok

but we need to

• consider how to guide users who wish to use a custom runner towards the APP protocol.
• maybe provide templates for the APP protocol.
• easily conver from other protocol to APP protocol.
• APP protocol maybe renamed to Custom

I'll need to think about it some more.

[majkinetor]

Both options would disrupt the current intuitive logic of using protocols with runners(user set one connection, and choose which runner to use when start connection).

I don't think that is particular loss of functionality. You would do so only while testing, not during normal work.

For example, after setting dynamic resolution, the option to set a fixed resolution should be hidden.

This is not comprehensive UI, its just convenient CLI helper so you don't have to handle large command lines yourself. Its really pain in the ass (I experimented a lot with FreeRDP and its really tedious without some form of helper).

Regarding mutually exclusive fields, as you can do the same in CLI, you can do it also on the UI. I would make this is as un-complex as possible if we are to go with this, for the start. We can always improve on it later.

The built-in RDP client, VNC client, and S/FTP client in 1RM cannot be launched using "cmd [string, mandatory]".

This is not for built-ins, they should work as is. This is relevant just for the App connection.

When modifying custom protocols, all connection configurations for the modified protocol need to be updated. For example, when renaming a field.

Yes, but why would you modify it? CLI tools do not change parameters names. Renaming a field would work too - changing a format of the field would not.

Based on 4, if we use a team database to store connection info of the custom protocols, we need to synchronize the custom protocol configuration files within the team and it may conflict

Its just an app (protocol or not). Current apps also suffer from this - imagine you have a different app on team computer with the same name or newer version that is not compatible.

I was thinking about team sharing protocols, but it doesn't seem to be worth the trouble. People can synchronize manually by taking a JSON array and importing it... Its not only that, apps need to be installed, you can't just sync definition. We could provide in app definition install script to do so, but that is huge security issue (we could work around it though, with some prompts/warning/officially-approved-scripts etc.) but that all introduces complexity that could always be developed later, when we get production insights and how much is feature actually used.

maybe provide templates for the APP protocol.

The Option 2 is form of a template :) And why would you need a template, you can always treat any App connection as a template as you can copy it.

easily convert from other protocol to APP protocol.

Why? 1RM doesn't have to fulfil any promise from PRM.

[VShawn]

This is not for built-ins, they should work as is. This is relevant just for the App connection.

but in option2 you said Remove protocols UI in configuration completely I think that means built-ins will be involved into option2

And why would you need a template, you can always treat any App connection as a template as you can copy it.

Yes duplicate can be tread as template, but without a template it will be painful when creating the first connection.

My template means:

Why? 1RM doesn't have to fulfil any promise from PRM.

because I may create a SFTP connect today and want to turn in into WinSCP someday, if there a conver to conver built-in SFTP into APP protocol, it would be nice. Obviously, for a new user, it's easier to first create an SFTP connection and then realize that they can use WinSCP to initiate the SFTP.

[majkinetor]

I think that means built-ins will be involved into option2

Nah, I thought only about custom protocols.

because I may create a SFTP connect today and want to turn in into WinSCP someday

Even today 1RM keep existing fields when switching to another connection. This could be also done when switching to App, after which you could select WinScp "template".

That auto filled CLI you mention is exctly one of the points of Option2. In above case given the definition of Winscp "Login with password" would be specified with 4 HPUP flags instead of hardly readable sentence you shown in the screenshot. For this particular case we would need combination of flags into a single CLI format though, I could easily give example, if you are up for going with it. The above example is not meant to be exhaustive, just idea at this time. In any case, "Login with password" would be typical "calculated" field based on other fields (in this case HPUP).

[majkinetor]

So I see you did harder option.

Where is the app definition stored? I see that when I type wfreerdp.exe, CLI definition pops up.

I know its preliminary but here are some bugs:

• Hint overlapping with err
  details

  
  
• Preview does nothing for me (let me just copy text)
  details

  
  
• Name doesn't accept space, but it can be copy pasted
  details

  
  
• Flag can not be added
  details

  
  
  
• Errors stay on top
  details

  
  

Also, I think this is spam

Also, what does Protocol mean ?

[VShawn]

Yeah, just the raw version, still got a lot of issues. I'm pretty busy this week, so I plan to do some light refactoring when I am free. Will continue working on the app protocol next month.

Preview

The purpose of "Preview" is to preview and test(by the run button) whether the command line is correct.

moving button

and moving button does make sense for some cli like winscp:

On WinSCP, you can't arbitrarily change the order of command-line parameters. Therefore, when editing the protocol, it may be necessary to adjust the order of the parameters.

as the gif shows chaning order will break the cli rule:

1.mp4

Protocol

Protocol session allow user renamed the protocol name.

[majkinetor]

I understood all the things except protocol :)

Regarding preview, it still does nothing for me, it just opens empty shell. Thats why I said that it would be good to give option to copy it as text.

[majkinetor]

So where is the app definition currently stored?

[VShawn]

So where is the app definition currently stored?

Currently, they are written in the assets and cannot be customized yet. I hope that in the future, users will be able to add new entries through a duplicate button, although I haven't fully figured out the details yet.

I understood all the things except protocol :)

It's just to ensure the protocol name is displayed correctly. For example, if you have configured "FreeRDP" you would like its protocol to be displayed as "RDP" instead of "APP."