Despite being disappointing, this is actually a correct result - you would get the same with OS level tools

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.

In addition to talks mentioned by Luca, I will be hosting an Experience Lab "Containerising Apps with IRIS" where you will be able to build and publish your own container with IRIS-based application: Tuesday 1:30PM and Wednesday 12:00PM, you need to pre-register but there are still spots available for both time slots.

Hi Jude,

For questions like this you should use TRC -- this is likely related to your environment setup which shouldn't be shared publicly and there are not many Trak people on the Developer community anyway.



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

One thing to consider is that Community Edition has a restriction on how many additional namespaces and databases you can have (and that's exactly zero). So while it may be nice to be able to have 3rd party tool in it's own database, it would also be nice to be able to use it from within USER and %SYS.

  • The easiest to start and learn and run samples and look around is Studio since it already comes with Cache pre-installed and you don't need to install or configure anything else.
  • Once you are ready to start with your project, switch to Atelier since it comes with integrated Source Control which is essential for project development.

OK now I'm curious where it was originally posted! :)