While we have multiple architectures, it makes now it quite tricky to make IRIS for both x64 and arm64

You can look at this example, where we build IRIS Community with ZPM

IRIS ARM64 does not work in emulated arm64, so, when you use some CI, which supports only x64 and offers qemu emulation to run ARM64 it will probably not work

So, you may try do not start iris inside ARM64 builder, but just add some binires required

Check this template https://github.com/intersystems-community/iris-fhir-template/blob/master...

// Configure FHIR Service instance to accept unauthenticated requests
 set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(appKey)
 set config = strategy.GetServiceConfigData()
 set config.DebugMode = 4
 do strategy.SaveServiceConfigData(config)

In my project iris-vector, there are a few things, which make it impossible to make it ObjectScriptLess, at least for now. 

  • I've already mentioned the issues of running Python based SQL functions, in my article, so, I had to add ObjectScript realization too.
  • And any new DataType in IRIS, which implements custom serialization based on methods like DisplayToStorage, at the moment accepts only ObjectScript, due to tied implementation to SQL Compilation engine.

A bunch of services with their InboundAdapters, such as FTP, Email, SQL, Kafka, and so on, connects to external server using this InboundAdapter directly, collect data and use it in Service. 

And only for TCP, HTTP, SOAP, REST by some reason decided that InboundAdapter now should start our own server, so, external services should connect to us. It's useful for sure, but the why we can't use it the other way too, is it somehow completely different? The logic in the workflow is still the same, it's Input data, which have to start the workflow.