New post
Discussion
· Feb 11, 2019

Tools and Framework Development and Deployment Guidelines . What is The Best Approach?

#Deployment #Caché #InterSystems IRIS #Open Exchange

Hi guys!

Suppose you developed a tool, framework, library on InterSystems ObjectScript for InterSystems Data Platform, share it via Open Exchange and want people to install it. 

What is the best strategy if it is a library and supposed to be called from different namespaces?

Here are the following thoughts:

1. Tool's developer should be able to use globals to read/store data the tool needs.

2. Tool's consumer should be confident, that the thing he/she installs will not harm the application's data.

3. A tool should be callable from any application's namespace.

4. Tool's installation(in general) should not request manual security changes (e.g. grant the write access to IRISLIB) and %YourClass is not an option.

5. It's easy to uninstall the tool - just delete the namespace/database (maybe delete some web-apps too).

In this case I see the following scenario acceptable the most:

1. Every new tool should install itself into a new special namespace and database for your tool. E.g. COMMUNITYLIB. Use %Installer fro then.

2. If you need the tool to be called from other application namespaces, map classes to a %All.

Here are the good examples of this type of tool installations:

RESTForms, DeepSeeWeb, MONLBL  - install itself into new namespaces/databases.

Not perfect examples: 

WebTerminal, ClassExplorer - need write access to the %SYS namespace.

Thoughts?

Discussion (10)3
Log in or sign up to continue
John Murray · Feb 12, 2019

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.

0 0
Evgeny Shvarov · Feb 12, 2019

Hi John! Thanks for the input. 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?

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

Agree, this is valuable. If we'll see thousands of modules. If we have a public package manager this will solve it I guess. But maybe "package name=repo name" rule could be a solver.

- What's the upper limit on namespaces? Databases?

I guess we have it in docs, but this number is large. Thousands I hope.

- 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.

One of the options when tools could safely share one namespace when it has the same publisher. We often can imagine one company/developer who produces several tools which probably can be installed into one namespace/database. 

0 0
John Murray · Feb 12, 2019

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.

0 0
Sergei Shutov · Feb 17, 2019

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
0 0
Evgeny Shvarov · Feb 12, 2019

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.

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?

0 0
John Murray · Feb 12, 2019

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.

0 0
Evgeny Shvarov · Feb 13, 2019

Yes, you are right.

I guess it is fair for the cases when the tool spawns jobs and does some work as daemons - like services, monitoring, alerting, etc. In this case data stays with XYZ database.

But I agree that we need a public registry of "safe" Class/Global prefixes and names.

We can take some easy and obvious approaches: Github or DNS.

E.g. with the Gihub approach the package name can start with a company.reponame.

Thoughts?

0 0