OpenTag implements an API that is designed to give the user the ability to work with DASH7 networking. For more information about the API and how to use it, check the API article linked about. This article describes the implementation of the API in OTlib.
The ALPs below are all API-like in that they map to functions in OTlib
OpenTag follows a client-server architecture and the roles of client and server ALP APIs are mirror images of each other. The Server ALP implementation must parse/process incoming ALP messages, take the corresponding actions, and then respond using some valid return data specified in the ALP. The Client ALP implementation is basically a sandboxed, function-based implementation of OTAPI, where the function calls are converted into ALP messages and sent to the server to be parsed. Therefore, an OTAPI function call on a client gets converted into a message that gets re-converted to an OTAPI function call on a server.
The Client ALP API is implemented via OTAPI.h, alp.h, and alp_api_client.c. Typically, MPipe and NDEF are also needed to push the message onto the server, although technically a client and a server could be implemented on the same device as two processes. In this case, any interprocess pipe do the work of the MPipe.
The Server ALP API requires all of the alp… files in OTlib/ to be present and compiled. If the server build is configured not to use one or more optional ALPs (via the Application configuration), there are preprocessor conditionals in the alp…c files that will prevent that code from being built. Therefore, it is best to put all of the alp…c files into you makefile or project and to use the application configuration to select which ones get built.