Hi Nikita,

> A need to change how the self-update mechanism works or shut it down completely.
If a package is distributed via package manager, its self-update should be completely removed. It should be a responsibility of package manager to alert the user that new version of package is available and to install it.

> Thus, create an additional pipeline (or split the codebase) for 2 WebTerminal versions: ZPM's one and a regular one with all the tests and
so on.
Some package managers allow to apply patches to software before packaging it, but I don't think it's the case for ZPM at the moment. I believe you will need to do a separate build for ZPM/non-ZPM versions of your software. You can either apply some patches during the build, or refactor the software so that it can run without auto updater if it's not installed.

The whole purpose of package manager is to get rid of individual installer/updater scripts written by individual developers and replace them with package management utility. So that you have a standard way of installing, removing and updating your packages. So I don't quite understand why this question is raised in this context -- of course package manager shouldn't support custom installers and updaters. It might need to support Projections eventually because as you said it's a part of language, but definitely not for installing purposes.

Just as a side comment, this has actually nothing to do with cookies. Cookies don't protect against CSRF. This is a custom HTTP header with a word "Cookie" in its name. So while it's correct it's a bit confusing.

I was not sure if checking for just presence of the header and not an actual value is enough (we assign a random value at logon time and store it in session), but apparently all browsers prevent cross-site AJAX requests so 3rd party site can't send custom header.

In that case I think it would be nice to have several ways to distribute a project:

  • "compiled" / "binary" version in form of IRIS.DAT which can be added to IRIS instance as a database and then either used in separate namespace or mapped into an existing one or %All, with clear instructions on naming conventions and how to use
  • "source" which can be imported into new or existing namespace and then changed (gitHub profile is enough for this type of distribution)
  • for a standalone type of tool, a Docker image which can be easily run or used as a sample/demo

You can use $zu function directly with third parameter

$ZU(171,1) returns CPU time (in milliseconds) on any OS, as a string in format SYS_time,USER_time
$ZU(171,1,pid) returns total CPU time (system + user) for process pid.

However this will return CPU time -- the time CPU was actually serving the process, not the time since process was started (when process is idle, this counter does not increase). Eduard's solution would be better if you need the total time.

I believe it's enough to have [Final] keyword set in deployed mode to give a developer a hint that this class should not be extended.

If you want to enforce this behaviour, I would add a check into each method as a first line , something like

if $this.%ClassName(1)'="My.Class" quit $$$ERROR(50000,"don't extend this class")

Since all code will be deployed, developers will not be able to remove this check easily.

You can also try to add a method-generator, I believe when you have a deployed class with method generator it will not be able to compile a subclass without method generator's source (though I'm not sure).