2 Basic type specifications

Basic type specifications denote that the type of the data to be read is one of the MP atomic types or an extension supplied in a dictionary as a Basic TypeSpec. The atomic MP types are the non-operator types: those that cannot have arguments and can only appear as the leaves of a tree. A distinction is made between a datum sent with and without the packet header. The former are prefaced with MP_ and the latter with IMP_. For example, MP_Sint32 corresponds to a node packet containing a signed 32-bit integer, requiring 4 bytes for the packet header and 4 bytes for the data. Sending a complete node packet is useful if we need to attach different annotations to that node at different points in the data. IMP_Sint32 indicates that the integer is to be sent without a node packet header, that is, as (part of) a data packet. It is not possible to attach annotations directly to data in a data packet.

The specification of MP basic types is done using CommonMetaBasicPackets (CMBPs) whose value specifies the type of some data that will appear later. The value of a Common Meta Basic Type is an integer encoding identifying a basic type. Section 4.3.3 discusses user-defined types defined in a dictionary. The following simple example makes this more concrete and helps motivate the discussion. We encode an array of 1000 IMP_Real32 numbers as shown in Figure 3. COP indicates a Common Operator Packet. Note that the prototype specifies that the elements of the array were transmitted without corresponding node packets (IMP_Real32 is used instead of MP_Real32) on line 3, so only the actual data from the array is transmitted in the MP tree that follows the prototype.

  

Figure 3: An array of 1000 IMP_Real32 numbers

Line 1 tells the receiver that what follows is an array of 1000 items. The prototype on lines 2 - 3 indicate that each element of the array is of the type IMP_Real32. Recall that ``IMP'' indicates an instance of the data type and not a complete node packet of that type. The data follows (line 4 on), but without node packets to individually specify the type of each element. For an array of 1,000 32-bit floats, the data requires 4,000 bytes and an overhead for the node packet headers of 4,000 bytes. Using the prototype to specify the element type of the array reduces the total size of the array's encoding from 8,008 bytes (4,008 bytes total overhead) to 4,016 bytes (16 bytes of overhead). An important point to make about prototypes is that the size of the prototype is largely independent of the size of the data. In the example above, the overhead for the prototype stays at 16 bytes even if, for example, the size of the data doubles (4 to 8 bytes for an IMP_Real64) or the length of the array increases.