Improve how connections are defined in settings

[gjsjohnmurray]

I am opening this issue to start a discussion.

Current situation

An extension's settings can be held in several locations, such as:

• settings.json for the user
• XYZ.code-workspace file if used
• .vscode/settings.json in the current root folder

More details in VS Code docs here.

In this extension the settings for how to connect to an InterSystems server are currently (as at 0.8.6) held in a structure that can only define a single connection. Below is the JSON of the default instance of this structure:

"objectscript.conn": {
    "active": false,
    "host": "localhost",
    "port": 52773,
    "username": "_SYSTEM",
    "password": "SYS",
    "ns": "USER",
    "https": false,
    "docker-compose": {
        "service": "",
        "internalPort": 52773,
        "file": "docker-compose.yml"
    },
    "links": {}
}

This is a significant restriction at user level. On my workstation I can only define a single connection.

When the connection is defined per workspace (in XYZ.code-workspace or in .vscode/settings.json) the limitation is tolerable, but it obstructs the use of multi-root workspaces and the isfs scheme to span multiple servers.

Contrast this with how InterSystems IRIS Server Manager allows definition of multiple named connections.

Proposals

Below is intended as a discussion-starter.

1. Use an array, subscripted by a user-defined name for each connection. The extension's definition of the settings it contributes can validate names against a pattern, e.g.

"intersystems.servers": {
    "type": "object",
    "description": "Target environments. Each property names a server and holds nested properties defining how to connect to it.\nServer names may only contain characters 'A' to 'Z', 'a' to 'z', digits, '.', '-' and '_' characters.",
    "scope": "resource",
    "default": {
        "localhost": {
            "host": "localhost"
        }
    },
    "patternProperties": {
        "^[A-Za-z0-9_\\.\\-]+$": {
            "type": "object",
            "description": "A server definition, with properties that specify how to connect to it",
            "properties": {
                "host": {
                    "type": "string",
                    "description": "Hostname or IP address of target InterSystems environment.",
                    "anyOf": [
                        {
                            "format": "hostname"
                        },
                        {
                            "format": "ipv4"
                        },
                        {
                            "format": "ipv6"
                        }
                    ],
                    "default": "localhost"
                },

                ...

            }
        }
    },
    "additionalProperties": false
},

2. Align connection properties with the settings that the existing Server Manager lets users define. For example, these cater for:

   • Connecting to InterSystems superserver as well as to to web server
   • InterSystems servers located behind a shared web server (i.e. not using the private Apache)

3. Separate the connection definition (which could be used by multiple extensions) from other settings (e.g. "links", and maybe also "docker-compose") that are extension-specific. Extensions should store connection-specific settings in their own array keyed by server name as defined in the intersystems.servers structure above.

[mvhenderson]

@gjsjohnmurray I totally agree - see #119 for my take on it which is primarily concerned with moving the details out of the workspace/folder settings in into user settings. This way we could checkin the .code-workspace file with project rules without exposing host/ports/credentials.

[MaxAbrahams]

I disagree - I think the current one-connection-per-workspace is correctly aligned with VSCODE's philosphy on what an IDE is supposed to do. I have found the use of multiple workspaces freeing compared to studio, atelier, etc. when it comes to managing both my local filesystem and the database's compiled classes.

I think this proposed solution is significantly more complicated than a small change in the user's organization strategy and development mindset. Im not sure I understand your point about multi-root workspaces being needed over using multiple workspaces.

[gjsjohnmurray]

@MaxAbrahams suppose you have two IRIS instances, DEV and TEST, each with an APP namespace on it. With the current objectscript.conn syntax I don't think you can create a single workspace that accesses both, like this (done with Serenji)

[bourette]

Hi John, You should be able to create a settings.json in the folder for each server/namespace.

…

On Fri, May 22, 2020 at 9:36 AM John Murray ***@***.***> wrote: @MaxAbrahams <https://github.com/MaxAbrahams> suppose you have two IRIS instances, DEV and TEST, each with an APP namespace on it. With the current objectscript.conn syntax I don't think you can create a single workspace that accesses both, like this (done with Serenji <https://marketplace.visualstudio.com/items?itemName=georgejames.vscode-serenji> ) [image: image] <https://user-images.githubusercontent.com/6726799/82673216-66ccfb00-9c39-11ea-8fd1-f408c5a04246.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4JU3FIWRQ27CLPIJKFLBTRSZ5WBANCNFSM4ND3EDCA> .

[gjsjohnmurray]

@bourette I am specifically referring to the use of the isfs scheme to connect VS Code's Explorer directly to namespaces and operate server-side (think Studio, not Atelier).

[bourette]

Yes, for each isfs scheme I also have a work folder defined which contains the settings file. James

…

On May 22, 2020, at 3:01 PM, John Murray ***@***.***> wrote:  @bourette I am specifically referring to the use of the isfs scheme to connect VS Code's Explorer directly to namespaces and operate server-side (think Studio, not Atelier). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[gjsjohnmurray]

Yes, for each isfs scheme I also have a work folder defined which contains the settings file.

@bourette I don't understand what you mean. Please post the (sanitized) contents of a .code-workspace file that you open in VS Code to give you a multiroot workspace accessing multiple servers with the isfs scheme.

[MaxAbrahams]

@gjsjohnmurray right, i get that you can't have two connections in a single workspace. my question was - Why is 2 workspaces, (i.e. one for DEV[APP] and one for TEST[APP] in your example) not an acceptable workflow? I personally find it preferable.

[MaxAbrahams]

if the complaint is simply the clutter of having two workspaces open simultaneously, consider a plugin like this

[EDIT]
i believe the confusion comes from the use of multi-root workspaces. I don't think its correct to assume that your use case calls for multi-root workspaces; i believe your environment would be simpler and more organized without them.

[gjsjohnmurray]

@MaxAbrahams my proposal will not prevent you from working in the way you find preferable. The opposite is not true.

[bourette]

@JohnMurray here is the sample you were looking for. Basically it has two namespaces on two different ports, they could easily be different systems by defining the host as well. It's a bit overkill because the workspace defines the connection and then I also define the same port in Sys1.

…

On Wed, May 27, 2020 at 5:12 AM John Murray ***@***.***> wrote: @MaxAbrahams <https://github.com/MaxAbrahams> my proposal will not prevent you from working in the way you find preferable. The opposite is not true. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4JU3FKL4OYAROUFZUWFQ3RTTKPNANCNFSM4ND3EDCA> .

[isc-bspead]

@bourette - where is the sample? Should it be an attachment or inline? (I don't see either in my view of the issue)

[bourette]

Sorry here it is.
VSSample.zip