Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I would like to be able to have two or three different sessions and write only one script to deal with all sessions at the same time; for example, on one script I would like to have onLogRecord event for each and every session. This feature is very useful in building testing devices/software with multiple sockets/communication channels. Does IO Ninja have this capability?
@mohammad Welcome to IO Ninja Forums!
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!
onLogRecord()
log.StdRecordCode.Rx
onLogRecord
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).
transmit
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.
I see; thanks a lot for the complete answer.