Take a look at methods in the %SYSTEM.Encryption class.

Like many of the classes in the %SYSTEM package, you can easily access its methods via $SYSTEM, e.g.

USER>d $system.Encryption.Help()
'Do $system.Encryption.Help(method)' will display a full description of an individual method.
 
Methods of the class: %SYSTEM.Encryption
 
AESCBCDecrypt(ciphertext,key,IV)
     This method performs AES decryption in Cipher Block Chained (CBC) mode.

...

Right. And this is the reason why the tool with XYZ.Classes should be installed in XYZ namespace - in this way even if I map XYZ to %All all the data persistent data for XYZ.Classes will be stored in XYZ namespace, even if I use it from USER namespace, right?

This is only true if you explicitly add a global mapping of ^XYZ.* to the XYZ database (NB, mappings point to databases, not to namespaces). If you only mapped the XYZ package to XYZ, when an instance of persistent class of that package is saved from within the USER namespaces its data will get stored in the USER database.

Why do you think we need a prefix for globals? The matter to have a dedicated namespace/database for the tool frees us from this requirement, right?

If tool XYZ is installed in namespace+database XYZ and consists of classes in the XYZ package that's %ALL-mapped from XYZ, default storage for persistent classes in that package will use globals ^XYZ.* which will get stored in the default data database of whichever namespace the tool is used in (e.g. USER). These globals mustn't clash with globals created in the same place by a tool from a different supplier, or by the end-user's own apps.

If tool XYZ opts to consolidate user's data into the XYZ database, the natural way of doing this is with package mapping, in which case it's still necessary to avoid name collisions. There are ways the XYZ tool could use extended global references to route data into its private database, but this adds complexity.

Some initial thoughts:

-  There should be a central name registry, to avoid clashing on namespace/database names, package names etc between different package providers.

- Consider assigning a top-level reserved package name (also prefix for globals and routines), and a namespace/database prefix, to avoid clashes with names that end-users of the tools might pick.

- What's the upper limit on namespaces? Databases? Any relevant constraints for Community Edition of IRIS?

- Adding a namespace for each tool package will lengthen namespace lists in Studio, Portal etc. Maybe tools don't always need a namespace in front of their database. Ones that present a web app / REST interface probably do (at the moment) because of how the app config has to point to a namespace.

- Tools should be able to register stuff that needs to be run during environment startup and shutdown. The current need to create/edit %ZSTART / %ZSTOP routines is clunky.

To use our extension you have to install some code on the target server. This code works on the latest platforms (e.g. the IRIS 2018.2 Field Test container) and on versions back to well before InterSystems' Minimum Supported Version. Indeed, one of my targets is still on 2008.1.

So a single VSCode instance can connect to many different server versions.

Does that answer your question Robert?