A VIEW in SQL is basically a prepared SQL statement.
It has to be executed and assembled like any other SQL query.
MATERIALIZED VIEW means that the content is collected before hands and can be retrieved rather fast.
I saw the concept first with my favorite competitor named O* and they made a lot of noise about it.
{ favorite: because I could win every benchmark against them }

The typical WHERE condition in SQL relates mostly to some content of the rows you work on.
So it needs to be calculated and checked for each row you access.
Differently (and that's why I named it STATIC) is a WHERE condition that is independent of the rows you access.

In Caché you had an example of a WebSocket Server in namespace SAMPLES
With IRIS the samples are gone and require additional installation effort.

So I refurbished the code with some useful additions:

• independent of namespace
• timeout control from client
• readable communication log

This contains 2 classes:

A demo in traditional style COS

This was written based on a previous trial in .XLS
It is far from being perfect. Rather a challenge for
improvement in all directions (code, interface, ...)
So anyone feel invited to make it better.

Earlier I've written about command pipes.
This is the internal variant of a PIPE.

To make this more tangible and visible for you I prepared a small example
The scenario is to run a monitoring process that receives
input from an unknown number of sensors. (Could be Lab equipment or similar.)

This example is extracted from a long-running installation.
The purpose is to have simple monitoring of several servers at a rather primitive level.
Just slightly more intelligent than a raw PING. But still easy to integrate.
It avoids the overkill of information you are often confronted with while you are just
interested in the number of active processes or similar basic figures.
The example shows a basic skeleton that might be easily filled by your real needs.

It consists of 3 sections:

The Caché / Ensemble standard distribution contains in namespace SAMPLES
a nice example of a CSP page consuming WebService as a Client.
I have modified it not only to display the replies but to feed them back into a Global.
I used the classic Hyperevent to achieve this. The replies end up as a log in global^WSREPLY.
When there is no input anymore the page closes and goes away.

There are 2 versions with visible and hidden display during operation.
dc.WSCSP.reverseVerbose.cls and dc.WSCSP.reverseHidden.cls

*** archived ***

The question has come up several times and I saw mixed answers and no quick example

My personal preference is using CPIPE device as you get back exactly the output you will get at the command line interface of your OS .
The tricky thing is to stop reading in time.
The example just displays what you normally see in your console.
it becomes useful if you look for things that you can't get from any $system.whatever()

If you have worked with Caché Objects,
You know already all about Relationships (one:many , parent:child) ...
But you will not find a word on many:many relationships in the docs.

But I met the question quite often from new adopters of Caché objects:
"Is it possible to implement many:many relationships ?" YES - of course !