Fair enough.

Table with notifications should be available on all application servers via ECP or Sharding.

This way each server can be aware of all the messages and inform the clients in turn.

Check this discussion.

The recordings will be made available to all registrants on Friday this week.

Uwe Hering (uwe.hering at intersystems dot com) can send you the video files for subtitling / editing - please send him an email.

German is the language of the conference, but some sessions are in English:

• When is Artificial Intelligence Trustworthy?
• Convergent Analytics
• Making Machine Learning Actionable
• Enriching Master Data Management product KanoMDM with AI/ML

Legacy.

Their cloud hosting is not free but you can host it yourself.

How do you configure it?

Some ideas.

Right.

Great answer, but I'd like to add that there are two distinct cases for working with XDatas:

1. Where XData itself is an object of work (for example generating a part of WSDL spec and saving it in a class XData).
2. Where XData is just a container for miscellaneous data (for example a template with placeholders).

The code above works for the first case, but for the second case it might be preferable to create an independent copy of an XData stream so that no locking happens - this prevents XData object access/modification errors, especially in Dev environments. Furthermore objectless way of getting XData contents would be faster.

I usually use this method to get streams if my XData work falls into the second category:

ClassMethod getClassXData(className, xdataName) As %Stream.Object
{
    set stream = ##class(%Stream.TmpCharacter).%New()
    for i=1:1:$$$comMemberKeyGet(className,$$$cCLASSxdata,xdataName,$$$cXDATAdata) {
        do stream.WriteLine($$$comMemberArrayGet(className,$$$cCLASSxdata,xdataName,$$$cXDATAdata,i))
    }
    quit stream
}

This code can be further improved for most use cases by replacing a stream with a string.

I think $this would also suffice.