Creating a file with an unusual extension under a web application fails

[isc-tleavitt]

Setup: Studio project with a web application defined as part of it, being edited via isfs.
Create a file named "foo.something" - it doesn't show up in the tree (in some server versions). With one server version it fails silently; with another I get this error:
Unable to write file 'isfs://iscx-jira-base2:jira-base/csp/jira-base/scripts/foo.something?project=Jira' (Unavailable (FileSystemError): ERROR #16006: Document 'csp.jira-base.scripts.foo.something' name is invalid)

Given the differing behavior based on server version, some of this might be upstream. Regardless this seems related to a challenge @isc-bsaviano had mentioned re: determination of slashes vs. dots in filename conversion.

Server version where file just doesn't show up:
IRIS for Windows (x86-64) 2022.1.1 (Build 374U) Tue Oct 18 2022 17:39:18 EDT

Server version with noisy error:
IRIS for UNIX (Red Hat Enterprise Linux for x86-64) 2020.1 (Build 215U) Mon Mar 30 2020 20:23:13 EDT

Context: we have a project where we're managing groovy scripts via a web application (which is unusual, I'll concede).

[isc-bsaviano]

@isc-tleavitt Are these files already open when you start VS Code, or did you manually open them from the UI somewhere? In the latter case, the extension should "know" if your file is CSP or not regardless of extension. In the former case, I need to use a heuristic to determine that and groovy isn't a file extension that I configured to be automatically be CSP. You can add groovy to the CSP whitelist using a the objectscript.projects.webAppFileExtensions setting.

[isc-tleavitt]

@isc-bsaviano I had no idea about that setting - it does the trick. Thank you!!!

[isc-bsaviano]

If we find a way to accurately determine CSP or not for #1161 then we could use that mechanism for projects and not require this setting.

[isc-tleavitt]

If we find a way to accurately determine CSP or not for #1161 then we could use that mechanism for projects and not require this setting.

Makes sense - I thought it sounded related.

[isc-tleavitt]

@isc-bsaviano would you expect objectscript.projects.webAppFileExtensions to be specifiable via server-side settings.json (as described here: https://intersystems-community.github.io/vscode-objectscript/serverside/#configuring-storage-for-folder-specific-settings?

[isc-bsaviano]

Nope, it can't be set in folder-specific settings. Only User and Workspace. That's true for the vast majority of our settings. We use the default scope of window. More info can be found here.

[gjsjohnmurray]

@isc-bsaviano in principle this one could be re-scoped so it can be set server-side (i.e. per namespace), because projects are always worked on in the context of a namespace, right?

[isc-bsaviano]

Yeah, but is that really necessary? Unless you have a server with a %Studio.AbstractDocument registered for the groovy extension Tim's setting will be perfectly safe. TBH I struggle to think of any of our settings that really NEED to be set per folder/namespace.

[isc-bspead]

@isc-bsaviano - I think that additional context may be be helpful for you. For hosted applications which make use of server-side source control paradigm, we work hard to ensure that all configuration is centralized (on the server) or can be automated for use in the developer's IDE in order to make things as repeatable as possible without having to deal with per-application exceptions. With over 30 internal applications which my team could be called to look at or contribute to, uniformity = higher dev velocity. With Studio, a developer who has never touched AppABC can immediately access the environment and contribute to code with the following 3 simple steps (assuming they have credentials on that instance):

1. Ensure they have the latest version of Studio
2. Download the Server Definition file and import it into their Windows Registry to update the Server Manager listing
3. Connect to the server using Studio and start working

This works for all 30 applications, with the only exception being that there are additional steps required if they are going to do local angular development.

Our goal is to make it just as easy for a developer to connect to and begin distributing to any of the 30 applications using VSCode using a equivalently easy process. We need to avoid building a list of exceptions like "Add this line of code to this local VSCode configuration file if you need to work on App#24".

This is why being able to control development behavior via the server-side source control hooks / configuration, or via a single configuration file which the developer downloads to add the servers for an application to their local list of servers to connect to is very important.

[isc-bsaviano]

@isc-bspead I understand the pain point, but we don't have a better way right now. If you know ahead of time what file extensions you will be putting in CSP applications beyond what is already handled, you can generate the code-workspace file with the setting built in. This all comes back to determining if a file extension requires dots or slashes as a separator without spamming the server with REST requests.

[isc-bspead]

Thanks @isc-bsaviano ... I just wanted to make sure you had the big picture from our perspective. Hopefully the work for #1161 would make this need moot at some point. In the field, we don't have control over the extension types that people use with CCR Transport (which relies on web application path access via the IDE in order to use change control commands), so that is another place where not specifying individual file types is going to be important to keep things simpler for the users. But I understand that #1161 won't be solved overnight.