SAMP — Simple Application Messag- ing Protocol Version 1.11 - IVOA

Section 4 describes a Profile along the lines of (1) above, based on XML-RPC. This can be used directly by client and hub developers, in conjunctionwith the abstract interface description in Section 3, to write interoperableapplications. This is at present the only SAMP Profile which has been defined.Splitting the abstract interface and Profile descriptions in this way separatesthe basic design principles from the details of how to apply them, andit opens the door for other Profiles serving other use cases in the future.3 Abstract APIs and Data Types3.1 Hub Discovery MechanismIn order to keep track of which hub is running, a hub discovery mechanism,capable of storing information about how to determine the existence of andcommunicate with a running hub, is needed. This is a Profile-specific matterand a specific prescription is described in Section 4.3.3.2 Communicating with the HubThe details of how a client communicates with the hub are Profile-specific.A specific prescription is described in Section 4.3.3 SAMP Data TypesFor all hub/client communication, including the actual content of messages,SAMP uses three conceptual data types:1. string — a scalar value consisting of a sequence of characters; eachcharacter is an ASCII character with hex code 09, 0a, 0d or 20–7f2. list — an ordered array of data items3. map — an unordered associative array of key-value pairs, in which eachkey is a ¡code¿string¡/code¿ and each value is a data itemThese types can in principle be nested to any level, so that the elements ofa list or the values of a map may themselves be strings, lists or maps.There is no reserved representation for a null value, and it is illegal tosend a null value in a SAMP context even if the underlying transport protocolpermits this. However a zero-length string or an empty list or map may,where appropriate, be used to indicate an empty value.12