Legato
Legato

GoFiler Legato Script Reference

 

Legato v 1.4j

Application v 5.22b

  

 

Chapter FourFlow Control (continued)

4.15 Session Data

4.15.1 Overview

Scripts can share a data pool that transcends the life of a script and can be shared by multiple other scripts. There are other methods of store meta data, but session data is specifically designed to allow script to communicate and share information over time and threads.

Since session data is shared amongst scripts, programmers must be cognizant that their actions can potentially interfere with other scripts. When running in a closed environment where all the scripts are known and controlled by a single developer, it is less likely to run into conflicts. However, in a larger environment, particularly major applications, there may be many scripts running and relying on session data. For example, simply resetting the session data could be disastrous.

Session data is stored in an internal thread safe pool as strings. While started as strings, the data can be automatically converted to signed and unsigned integer types.

4.15.2 Identifying Session Data

Three separate items identify a session value: group, section and name. The name is primary but can be qualified by the other two strings. Group and section allow for organization and uniqueness to avoid conflicts with other scripts that may use similar naming structures and conventions.

Each of the identifiers can be up to 128 characters in length while the only required item is the name.

4.15.3 Limitations and Notes

Session data is stored internally in a conventional string pool, the same type of object that is used for String Pool Objects. This is convenient and relatively fast but it does have some limitations. First, the named values in the pool are not sorted. Second, pool space management is not sophisticated. Scripts should avoid, if possible, thrashing the session pool like standard variables.

For long-term operation, such limitations should be considered to avoid sluggish operation and excessive memory consumption.

Scripts should not assume session data is in a known state. Since session data lasts until the application is terminated, it can be set to any condition upon entry to a script. This is particularly true when debugging.

4.15.4 Background Scripts

A key facet of session data is the ability to ‘test and set’ data. How this works is, during the function call, a session variable can be tested for a certain state, and, if matching the condition, set to a new state or value. This is performed in a thread safe manner, allowing multiple scripts to perform locking and sharing operations without fear of conflict.

See the TestAndSetSessionValue function for more information.

4.15.5 Functions