This limit on Comunity Edition will be expanded with the next update.

Thank you, Vitaly! ObjectScript is full of opportunities! With a creative community, of course :)

But why "minus"? This is elegant and works.

You cannot, yes because of Accepted status. 

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?

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?

Thanks, Kyle!

Also, the option which worked:

ClassMethod valuesCollectionToDisplay(val, delim) As %String
{
  quit ..AsJSON(val)
}

ClassMethod AsJSON(val) As %String
{
  set res = []
  set ptr = 0
  while $LISTNEXT(val, ptr, el) {
    do res.%Push(el)
  }
  quit res.%ToJSON()
}

And the SQL call:

Select %EXTERNAL(values) values from data

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?

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.