Tools and Framework Development and Deployment Guidelines . What is The Best Approach?
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?
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.
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.
Hi Sergey! Do not take Community Edition limits into consideration.
If you don't have limits what is the best strategy with packages/tools development in your opinion?
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?
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.
I guess we have it in docs, but this number is large. Thousands I hope.
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.
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.
In that case I think it would be nice to have several ways to distribute a project:
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.
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?
This limit on Comunity Edition will be expanded with the next update.