Data Types
LightWave Supports supports the following data type names which may be specified in the type attribute of a dictionary file element.
type attribute value | Default size |
|---|---|
int | 4 |
short | 2 |
long | 4 |
longlong | 8 |
byte | 1 |
unsignedInt | 4 |
unsignedShort | 2 |
unsignedLong | 4 |
unsignedLongLong | 8 |
unsignedByte | 1 |
float | 4 |
double | 8 |
string | no default |
numeric | 18 |
numericSignTrailing | 18 |
numericSignEmbedded | 18 |
numericSignTrailingEmbedded | 18 |
unsignedNumeric | 18 |
base64Binary | no default |
hexBinary | no default |
boolean | 4 |
base64Binary
The base64Binary data type is used to transfer binary data through a LightWave Server API using base64 encoding. When a field is defined with type="base64Binary", LightWave Server automatically base64-encodes the field data for the wire payload and base64-decodes incoming data back into the IPM field.
Because base64 encoding expands the data, the encoded (wire) representation is larger than the original binary data. The encoded length is calculated using the following formula:
encoded length = ((decoded length + 2) / 3) * 4
For example, if your application produces a binary payload of up to 1000 bytes, the base64-encoded size is:
((1000 + 2) / 3) * 4 = 334 * 4 = 1336 bytes
Sizing Fields for base64Binary
When defining an IPM field for base64Binary data, you must account for three distinct sizes:
Decoded payload size — the size of the raw binary data your application produces or consumes. This is the actual data you are working with.
Encoded (wire) size — the size of the base64-encoded representation transmitted over the wire. This is always larger than the decoded size, calculated by the formula above.
IPM field size — the size of the field in your DDL definition. This must be large enough to hold the encoded data.
Size the IPM field using the formula: ((max decoded payload size + 2) / 3) * 4. For example, to support a maximum decoded payload of 1000 bytes, define the DDL field as PIC X(1336).
Using sizeIs with base64Binary
When the actual size of the binary data varies from message to message, use the sizeIs attribute to reference a companion field that contains the actual length of the data. This tells LightWave Server how many bytes of the field to process, rather than always processing the full field size.
The following DDL example defines a base64Binary field with a companion length field. The field is sized to hold up to 1000 bytes of decoded binary data (1336 bytes encoded):
?COMMENTS
DEF BINARY-DATA-IPM.
02 RQ-CODE TYPE BINARY 16.
02 BINARY-DATA-LEN PIC 9(9) COMP.
* @LightWaveAttribute(type="base64Binary",sizeIs="binaryDataLen")
02 BINARY-DATA PIC X(1336).
END.
The Dictionary Manager generates the following dictionary XML:
<type name="binary_data_ipm">
<element name="rqCode" type="short" offset="0" size="2"/>
<element name="binaryDataLen" type="unsignedInt" offset="2" size="4" hide="1"/>
<element name="binaryData" type="base64Binary" offset="6" size="1336" sizeIs="binaryDataLen"/>
</type>
In this example, the BINARY-DATA field is sized at 1336 bytes to accommodate the base64-encoded form of up to 1000 bytes of binary data. The BINARY-DATA-LEN companion field holds the actual number of encoded bytes to process for each message. The hide="1" attribute on the length field means it is not included in the wire payload — LightWave Server uses it internally to determine how much data to encode or decode.
For transferring large binary payloads that exceed IPM size limits or require raw (non-base64) handling, see Using BLOBs.