IO Ninja doesn't have this capability. It's not that it's technically impossible, but it would complicate a lot of things and what's more important, would be very difficult to use.

Imagine, your onLogRecord() callback is being called for each and every record in all opened sessions. How do you distinguish an incoming log.StdRecordCode.Rx block of one session from that of another? The only way is to introduce some sort of a session identifier and pass it to your callback. Now, this raises questions. First, what this session identifier should look like? Session title? It is not unique, and strings are not cheap to conditionally branch on in your script (for each added log record!). A number? You would need to somehow look up (or assign) this identifier for each open session. OK, let's say we have this identifier. But adding session-specific branching to your script essentially "binds" it to this particular set of open sessions! What if you close and reopen IO Ninja and start a different set of sessions? You would need to update your onLogRecord callback every time!

The same reasoning applies to transmit -- you would need to somehow specify which session to transmit data to (and again we gonna have session identifiers and the need to update your script if the set of open sessions changes).

Another consideration against such design is that each session is running in a dedicated process, and having such a "supervisor" script would require passing memory blocks across process boundaries -- which is not a cheap operation.

So I strongly feel like keeping it as is -- in-app scripts are running in the context of a session process, so they are strictly per-session. onLogRecord is called for records of this particular session, and transmit sends data again to this particular session. Also, calling onLogRecord() is relatively cheap. It doesn't even involve in-process memory copy! We create a so-called pointer validator -- to prevent your script from accidentally (or intentionally accessing or corrupting memory beyond the log record block -- and pass it directly to you onLogRecord().

Overall, this is a much simpler and cleaner design.