This should have been the accepted answer. :) It is more important for code to be easy to read than for it to be easy to write.

I have enabled and used that feature in older versions as well; it is really useful. I have a PuTTY setup with a key pair that starts the IRIS terminal in docker on a remote machine, without any password, but still safe. (I wanted to use my regular account name as well, so I had to do some additional setup in the container, but the principle remains the same.)

Anyway, that explains why there's no need for a password anymore, thanks!

By the way, I have not een an announcement that 2019.3 became an official release, did I miss something? (I also see no Studio for 2019.3, and the 2019.4 preview Studio download doesn't work.)

Thanks for that, Evgeny, that does clear up things a bit. I hope Luca responds as well about the Quiesce... and SetMonitorState calls. I get the impression that things relating to creating containers are still changing rapidly. I do find the backslash-escaped multiline commands annoyingly ugly; your post above made that a bit better, compared to what was there before. (I'm hoping some of the ugly boilerplate will be delt with by ISC "inside" the container eventually.) I'm going to play around with your template a bit when I get the time!

This looks like a convenient way to handle things. It would be good, though, if someone could explain what the various ObjectScript commands in irissession.sh are needed for. I also see no credentials being passed?

That link works. But if I search with Google (or DuckDuckGo), the first link that comes up for me appears to point to the proper page, but opening it loads a page about  SOAP Session Management. Many other links from Google end up on that page as well. The key in the docbook URL is ITECHREF_macro, that looks ok, so it seems the ISC docs are broken somehow.

Nice, I didn't know this. The IRIS docs appear broken at the moment, but this is documented here.

This datatype is not present in (currently latest) Caché 2017.2; it appears to be IRIS-only. That rather limits its usefullness. Besides, what is the performance of a datatype, and where is that a bottleneck?

If you add a property with an XMLPROJECTION set to CONTENT, it should be output without the wrapping tags. E.g.:

Property content As %String(XMLPROJECTION = "CONTENT");

Regards,
Gertjan.

It appears to be enabled when I try here, but I haven't used recordmaps much so I don't have one fully configured. I see another setting for the encoding in the record map properties itself; perhaps this is where things should be configured? (That would also explain why the adapter setting is disabled: you want to configure this only once.)

Unfortunately, long strings can't be 3GB, but rather almost 3.5MB. For any sane usage of JSON this should be enough, but I've seen REST APIs where e.g. PDF streams are returned in base64-encoded JSON properties, that come uncomfortably close to that size.

It would be really nice if the %DynamicObject class added support for streams to deal with these large payloads!