• The idea of this package is to compare the performance of columnar storage    inside IRIS without wrapping it to some foreign platform that is not my world   
• In addition, I do not want to measure network performance between 2 containers,     but inside a closed IRIS environment that I have fully under my control
• Even the use of SMP or some other browser-based presentation has some influence that I want to avoid.
• Measuring should be as close to the core as possible. So I flagged it NATIVE. Some people might feel it is ABORIGINAL.

I want to address the nasty problems about reading a flat text in ASCII, UTF*
explicitly excluding HTML, EBCDIC, and other encoding.
According to Wikipedia there are at least 8 variations of control characters.

• CR+LF is typical for Windows
• LF is typical for the Linux/UNIX world
• CR is Mac's favorite

As you can deduct from the names the inspiration comes from mechanical typewriters.

In IRIS* similar as in Caché or Ensemble or .

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you did a major change and expect a changed review just let me know.

While creating my latest examples for the JavaContest I faced the need
to communicate with my code from a program in IRIS to my Java code.

Communication with |CPIPE| worked as READ or WRITE  but not both?
In the Documentation Named PIPEs are explained rather shortly.
"Once open, a pipe acts like an ordinary device."  Not so precise.
I failed to achieve my expected READ/WRITE  as TCP would offer. 

Has anyone a working example to demonstrate it? 
Any suggestion is welcome.

I found a workaround for my actual case.
Though I'm not so happy with it.

Based on the successful solution for my 2nd contribution to the Contest 
I used an adapted version for this package. And have some findings I'd like to share.

Multiple communication steps over CPIPE may take time.
You won't recognize it on a fast machine. But a slower box with
Windows + Docker Desktop + your browser (and more) is neither
"Speedy Gonzales" nor a "Road Runner". 🙂

First observation you launch your OS command and see NO result
On the console, you just sit there and expect a reply.
Establishing the Connection to IRIS is a typical case.
Jour redirected Output is just empty.

There are situations when your only access to a server is using a web browser,
and there is just no chance of a Terminal or Console access.
The Online Demo Server is such a case.

So you have WebTerminal. That's fine for ObjectScript and Embedded Python.

But my demo is straight Java. And is interactive.
$ZF(-100...) is some aproach. But it's rater batch-oriented and not interactive.
@Enrico Parisi  presented a nice extension to WebTerminal recently.
It's close to my own packageWebCommand that I presented a year ago.

This is the related article to the package in Java Contest. 
I decided to present a CRUD++ Global Editor based on IRIS Native API for Java.
++ because it’s a little bit more than just Create, Read, Update, Delete
Visualization of a global is always important to review results immediately.

• For this purpose, I have extended the API with a Tree Viewer that mimics  ZWrite and allows also the examination of subtrees.
• A $Query Style Navigator Forward and Reverse operating for easy finding the Global node of interest.

In my previous articles, I described my Command Line Extension to NativeAPI.
Of course, this is also available for any other NativeAPI package.
So I created this example as a demo for the actual Java Contest.

The package contains also an IRIS server in Docker for the demo
It is evident that it also works with any remote IRIS server.
You just have to provide it with my NativeAPI CommandLine Extension.

I think this demo is easy to follow and shows the essential features.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you did a major change and expect a changed review just let me know.

MIRROR is the best solution for almost immediate replications to a Failover Server.
The related mechanics are based on Global Journaling.

Globals hold Data and Classes and Routines and more ...
If Mirroring is in place all is in sync. With minimum delays
This is of course  rather useful for code changes in Classes, Routines, ....

To what extent is Embedded Python covered by Mirroring?
Or:
What is required to Synchronize EmbeddedPython like Mirroring. 

With ECP we have the option to have a collection of Frontend instances
All Frontend servers typically have a common Master in the background
Concentrating data on the Master server is the primary goal.

As a side effect, this applies also to Classes, Routines, .. anything stored in Globals.
This is probably not the most efficient setup. But rather common anyhow.

Is embedded Python code also stored in Globals?

What is the recommended solution for a similar installation?

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you did a major change and expect a changed review just let me know.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

In my recent post Quality of Open Exchange packages, I  tried to raise attention on
Pull Requests and Issues (on GitHub).
I could count the replies on 1 hand. Special Thanks to the French Community!
I see the role of a Pull Request as a proposal to fix a problem in the submitted package.

• If you agree you Merge it 
• If you disagree you Close it

Both actions signal to the creator of the PR that you got the message.
Doing Nothing, leaving it Pending is not just an unfriendly act to the creator but
also to anyone.of the community who wants to consume the repo. He is just left in the lurge.

The related package avoids adding %JSONAdaptor to each class but uses  instead   
SQL functions JSON_OBJECT() to create my JSON objects. With this approach, you can   
add JSON to any class - even deployed ones - without any need for change or recompiling.

The trigger was the Export of M:N relationships  as JSON  objects or arrays.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

I've been running my review collections on OpenExchange now for more than 3 years.
I explained the principle I apply in a past article. 
These reviews are the first step of the quality check in OEX.

My personal Credo
My expectation of OEX  (expressed in extreme) is to see it rather as
a collection of jewels, than just a flea market.

I start this discussion encouraged by @Evgeny Shvarov in his recent comment 

The quality of Open Exchange is very important, of course! 
And we have a set of features and processes are intended to understand 
and improve the average quality of projects. And as OEX is a living 
mechanism it is not possible to "click" and improve the quality forever.

I appreciate your willingness to improve the quality and PRs submission. 
Please suggest what do you think could be introduced more to improve the quality. 
We'll try to make PRs more visible in Open Exchange.

And also the ideas on how to improve the quality of the submissions are very welcome! 

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review just let me know.

In a previous question, I have illustrated a few problems using Embedded Python
interactively as you would do from Docker console or IRIS terminal.
Investigation of the causes brought a rather clear picture. It's a classic impedance mismatch

• While consoles act rather relaxed WebTerminal is very precise in output presentation line terminators from (Embedded) Python's print() function are typically <LF>  0x0A  $C(10) And WebTerminal does exactly this while eg. my console in Docker also does a <CR> und cover. So a sequence of print() looks like a scale
• Compared to ObjectScript where a WRTE !

For my Embedded Python ONLY demo package I need some user input.
Similar to ObjectScript

read "say somthing",reply

I use the Python equivalent

reply = input("say something")

And this works excellent without problems  from Terminal or Doker console

BAD SURPRISE: 
withWebTermnial ObjectSscript works fine, but embedded Python fails badly.

I do not care about line terminators without <CR>
but it is just impossible to receive any input.

This is no improvement. The content is missing !!!!

QUESTION to the experts.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you did a major change and expect a changed review just let me know.

Inspired by a Question from @Evgeny Shvarov and a Reply from @Ashok Kumar Thangavel
I have created a base for Global download as XML file

How to use:
 just call the page like http://<your_server>/csp/samples2/dc.Gdown.cls?GBL=global_name
gbl-name  without the initial ^ (caret)
The output has a default name <global_name>.XML  Your choice is available.

Known Limits:

• you have to install it at your sourcing server
• it is not tested/working across namespaces
• there is no partial download
• error handling is just basic or missing

There is space for personal improvements.
and this is it:

ClassExtends%CSP.Page<<html<

In my previous articles, I described my Command Line Extension to NativeAPI.
Of course, this is also available for any other NativeAPI package.
So I created this example in Python as a demo.

As noted in the previous article Native API has some limits.
So I did some research on a more Terminal-like interface that
provides me with access like a console or the IRIS terminal
to allow my  $QUERY over a global and other nice commands
that are not supported/mapped in NativeAPI for ObjectScript.

The basic tools are well-prepared and available.

• Connection() creates a fully operational and stable partition for me
• Function() allows calling any routine or method I need
• similar ClassMethodValue and ClassMethodVoid

There is just no method CommandLine and some already prepared code is needed.

This question originally appeared in the comments of the post: Download globals from a particular server
 

This article was inspired by a recent question from @Evgeny.

A recent question from @Vivian Lee reminded me of a rather ancient example.
It was the time when DeepSee's first version was released.
We got Bitmap Index.
And we got BitSlice Index: mapping a numeric value by its binary parts.
So my idea: Why not indexing strings by their characters?
The result of this idea was presented first in June 2008. 
IKnow wasn't publicly available at that time.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you did a major change and expect a changed review just let me know.