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

consumers if appropriate. As far as possible, where new keys are introducedthey SHOULD be such that applications which ignore them will continue tobehave in a sensible way.Hubs and clients are therefore able to communicate information additionalto that defined in the current version of this document without disruptionto those which do not understand it. This extensibility may be ofuse to applications which have mutual private requirements outside the scopeof this specification, or to enable experimentation with new features. If theSAMP community finds such experiments useful, future versions of this documentmay bring such functionality within the SAMP specification itself bydefining new keys in the “samp.” namespace. The ways in which thesevocabularies are used means that such extensions should be possible withminimal upheaval to the existing specification and implementations.2.7 Use of ProfilesThe design of SAMP is based on the abstract interfaces defined in Section 3.On its own however, this does not include the detailed instructions requiredby application developers to achieve interoperability. To achieve that, applicationdevelopers must know how to map the operations in the abstractSAMP interfaces to specific I/O (in most cases, network) operations. It isthese I/O operations which actually form the communication between applications.The rules defining this mapping from interface to I/O operationsare what constitute a SAMP “Profile” (the term “Implementation” was consideredfor this purpose, but rejected because it has too many overlappingmeanings in this context).There are two ways in which such a Profile can be specified as far as clientapplication developers are concerned:1. By describing exactly what bytes are to be sent using what wire protocolsfor each SAMP interface operation2. By providing one or more language-specific libraries with calls whichcorrespond to those of the SAMP interfaceAlthough either is possible, SAMP is well-suited for approach (1) above givena suitable low-level transport library. This is the case since the operationsare quite low-level, so client applications can easily perform them withoutrequiring an independently developed SAMP library. This has the additionaladvantages that central effort does not have to be expended in producinglanguage-specific libraries, and that the question of “unsupported” languagesdoes not arise.11