Well, the issue is that Caché, or even IRIS, still uses one Job to process requests for the same session. So, anything higher than 1.1 will not help at all. So, the only solution is to make sure that as much more possible static files are processed without Caché/IRIS or WebGateway, through a webserver configured for HTTP/2/3. And only API requests which require data would go to Caché/IRIS, and best case if it will be session-less queries, meaning that your requests are not tied to the session on the server, and those queries could be processed in parallel, and everything needed can be reconstructed from the query, e.g. username to check permissions should go from Authorization header.

Moving from HTTP/1.1 to HTTP/2/3 is not as simple as you expect, differences between protocols are significant. And requires a lot of work on the application.

So, I think the best is to create an issue, describing what's wrong with inspectdb, what's missing in the models, and how you solve it, manually, and I could have a look and probably solve it on Django side.

Could you check if inspectdb is working for you?

python manage.py inspectdb

Check Django documentation for details

Well the current version of IPM allows to build and publish to some private registry deployed packages. 

So, for companies that would like to distribute their packages through IPM, they can install own registry provide authentication for users who bought their product, so they will be able to connect to the registry and install the package.

You can't publish manually to the public repository, you can do it only through OpenExchange, check IPM during application creation, and with the next release, it will publish your project for you

If you want to publish to your repo, you just have to specify login and password, with command like this

repo -r -n myrepo -url https://server/registry/ -user "test" -pass "test"

Not sure, but you can try

there any way should be available driver for Cache, which should work

I'm sure that the best way to test REST API would be to use some external tools, such as Postman/newman

You can look at my example project, which contains running tests against REST using newman

But it also contains some tests for REST on the IRIS side

dispatch class, which just named disp next to impl class, is generated and generated classes are hidden by default and you can show them with a flag in the Server Explorer. But, this class always regenerates, when you compile your spec file.

have a look at this example, of how I deal with errors

Another solution is to use getattr

classname="%SYSTEM.SYS"
methodname="ProcessID"
pid = getattr(iris.cls(classname), 'ProcessID')()

myerror=iris.cls("%Exception.PythonException")._New("MyOops",123,"def+123^XYZ","SomeData")
for propertyname in ["Name","Code","Data","Location"]:
    print(getattr(myerror, propertyname))

What’s the point of using Python and attempting to keep using ObjectScript functions, find python alternatives 

Python can do multithreading, do you can process in background 

and another way to access terminal through web, is by using ttyd, I use it for irissqlcli-web. ttyd helps to webify any terminal application, it can be bash, or iris session

You did not mention, what package you would like to use in Python to make REST. 

• if it's FastAPI, with this package you can use SQLAlchemy and sqlalchemy-iris 
• Django, with this framework, then just use django-iris

In any case, I would recommend looking into SQLAlchemy, and its API, which has many features, of course including the way to list tables, as well as list columns in tables, and lots of other features.

If you are going to use some other package for making REST API, and this library does not support SQLAlchemy, let me know, I'll have a look, and may implement IRIS for this library too.

Looks like the database was created with a different collation, and contains a few globals with this collation. 

I don't remember, but I think in the messages.log it should show which collation is expected. And then, you can change it in Management Portal, and with NLS. When you activate NLS which contains the expected collation, it will be able to mount this database.

This part I can do, but, I don't think we should even consider it. This is part of IRIS SQL Dialect, and it's not good when some SQL queries may not work with different connections, e.g. using JDBC, or SMP.

I think it depends on what type of application you have on IRIS.

If it's just some frontend application, then there is a variety of projects to do this task, as it is not much related to IRIS

What exactly do you want to test?

What happened to ARM64 images again?