The responder is responsible for the communication between the user interface (front end) and the system. The responder handles the input provided by the user, passes the input information to the system, and then responds to the user with the output provided by the system.

The architecture for the responder is as follows. It consists of three components.

1. Initiator
2. Service
3. Sessions table

Sessions Table

Sessions are used to keep track of multiple conversations occurring between users and the application at any given time. The sessions table a SQLite table within the Cuneiform internal database. This table holds details of ongoing sessions between users, and the application. Each user session consists of the following properties:

1. Session ID - a randomly generated unique identifier for the session
2. Intent - the current intent between a user and the application
3. Action Type - the expected user action
4. Last Activity - timestamp indicating the last time of activity between a user and the application

By default, a session has a lifespan of 30 minutes of inactivity. Afterwards, the session gets deleted. The inactive lifespan of a session can be changed by changing the max-age property in the config file within the responder.

Service

The responder service is a continuously running process within the responder. By default, this process runs on port 5001. This process is initiated when the application starts, by executing the start.py file. This process simply handles two tasks.

1. Routing message data between the initiator to the classifier
2. Periodically cleaning inactive sessions

The frequency at which the service cleans sessions is provided in the config file within the responder. By default, it scans for inactive sessions every minute.

Initiator

The user interface starts its communication with the responder through its initiator. When communicating with the initiator, the user interface must provide the current session ID, and the message in the form of a JSON object containing the keys "sessionid", and "message". If it is the first time the user is communicating with the system, and a session ID has not been assigned, the interface must provide a random session ID, less than 8 characters (eg: "123"), and thereafter, the system would assign a session ID to the user session.

Each time the initiator is providing a response to the user interface, it will pass along a session ID along with the message in the form of a JSON object. Each time this interaction occurs, the user interface must store the new value of the session ID for the user.

When the initiator receives a message, it validates the provided session ID with the existing sessions. If the provided session exists, it will get the session data, and pass the session data along with the message to the service. If not, it will create a new session with a new ID and pass the message details to the service.

The user interface communicates with the initiator by executing the responder.py file in the responder, and providing the necessary data through standard inputs.

When Cuneiform plugins are developed for conversational interfaces, the development process is very simple, as the only action that should be done is executing this file, while storing the session ID for the user.

The next section discusses the implementation details of the intent processor within the classifier.