Some technical background information
There is not just one class in this package: rcc.gstream.cls but also rcc.gstreamT.cls
While rcc.gstream works with direct access to the stream globals, the *T version uses
a Process Private Global (PPG) as Temporary storage.
using SELECT * FROM RCC.gstreamT WHERE RCC.useT('^jpgS')=1 and similar.
This might be an advantage for multiple access to the same stream in sequence,
The advantage is obvious: You have a personal snapshot in memory and no risk of
a conflict in access. This might be interesting if you work just on 1 specific stream.
The disadvantage is also evident: The merge from Stream Global to PPG takes time.
As a side effect I learned that the compression of stream variants GblChrCompress,
and GblBinCompress only affects the global size on disk. Once in memory, it consumes
the full size, and therefore with xDBC the full uncompressed stream gets sent over the
connection.
Differently, inside IRIX/Caché/Ensemble you only get to the stream's OID. Which makes
sense as streams typically exceed the maximum String length. To visualize this I did
something unusual as I mixed flat and compressed data into the same global.
So all even IDs are compressed streams.
The code in the repo is written for IRIS.
But using it in Caché/Ensemble/... only requires changing the stream storage type from
<Type>%Storage.SQL</Type> in IRIS to
The base for both classes is Global mapping with SQL Storage.
And it was quite an exercise to make it dynamic.
My personal thanks go to Mike LaRocca who created a presentation about 20 years ago
that I found in my personal archives together with a related similar aged document
"Mapeo de Clases persistentes en Globales" from a Spanish engineer
who's name was not mentioned there.
As a bonus for those who try the package, there is a medical jpeg not shown in the video.
I guess you will recognize the person immediately.
Hoping for your votes in the tools contest !
Video
.png)
.png)
.png)
.png)