To elaborate a bit: we are currently discussing two approaches on how to store intermediary representations of Messagepack message.

One of approaches is to store message as $lb(code1, code2, ... ,codeN) so that each character in message is stored as a corresponding code in $lb.

Other approach is to store as is in strings, so it would look like: $c(166) _ "Fringe".

Let's say we want to encode string "Fringe", it would look like this:

• $listbuild(166, 70, 114, 105, 110, 103, 101)
• $c(166) _ "Fringe"

I maintain that approach ASIS (with $c) is better as it gives less overhead than $lb.

There is no option to directly read 166, 70, 114... in Caché, only reading symbols and getting their codes from $ascii. So there would be a considerable overhead on conversion to and from $lb abstraction.

Docs.

When you  want to have two or more classes pointing to the same storage. Sometimes it can be useful to have one persistent class with full definition and another with only a few properties. I used this approach to test indices building on a test class - it does not affect existing class and it's indices.

2.  Write a routine to copy (duplicate) all the data from old classes to new ones. (which is not trivial at some point)

Why is it not trivial? If you're not changing class definition  three merges per class should be enough.

Also check that storage definition in the new class is the same as in old class, only pointing to the new globals.

MANAGEDEXTENT=0 may be easier to do, but it raises the risk of accidentally deleting old globals (what are these globals not corresponding to any class? Let's free some space)

Check your XML/JSON serializations, as you can get a loop easily (or output too much) with this architecture decisions.

Check that your XML declaration (encoding) corresponds to the actual stream).

I have a Cache-compatible sql script file and each query is separate by white space.

How do you escape white spaces in a query?

Anyway, the general approach is:

set file = ##class(%Stream.FileCharacter).%New()
do file.LinkToFile(filename)
while 'file.AtEnd {
  set query = file.ReadLine() // ???
  set rs = ##class(%SQL.Statement).%ExecDirect(, query)
  set sc = rs.%DisplayFormatted(format, outfile)
}

Where:

• filename - file with queries
• format - one of  XML, HTML, PDF, TXT or CSV.
• outfile - file to write results to

I assumed query separation by newline.

Also outfile needs to change between queries as %DisplayFormatted recreates it.

Duplicates are very similar.

You can try to use %SIMILARITY function available in Cache SQL.

You can use Session Events for logging, it provides OnStartRequest and OnEndRequest callbacks.

 Is it possible to know the user through the session, in the broker, or in the triggers?

Yes, you can store data  in %session object and retrieve it on a later date.

Also, check out my series of articles (part1, especially part2) on web debugging.

@Murray Oldfield wrote a great series of articles focused on performance and detecting bottlenecks. Check it  out.

Only after authenticated.

You'll need to:

• write authorization code
• control current authorization state 
• check that it all works as expected so  you don't consume more that one license per user

There's no reason to do that, as standard Caché tools, such as Login page provide all required capabilities.

Do you mean web-app settings like in the following screenshot?

Yes.

But why not using basic authentication? Can I consider using it?

It's way better to use CLP because this way Caché tracks authorization and licenses and you don't need to think about it in your app.

Here's some recommendations on securing REST + CSP web apps:

1. All brokers effectively have Parameter UseSession = 1;
2. REST web application and client web application allow only authenticated (i.e. password) access.
3. REST web application and client web application have reasonable Session timeout (i.e. 900, 3600).
4. REST web application and client web application have the same GroupById value.
5. REST web application and client web application have the same cookie path.

Client web application can have a custom Login Page (or just use default login page, that's okay too).