With some understanding of how ZeroMQ and request-reply systems work, we will now design the automation system. We'll start by going over some design considerations and use cases.
Normally, a server deals with many clients, usually concurrently. It can do this because of the design of most servers: all state changes, like withdrawing money from a bank account, happen in something like a database. The server processes themselves are stateless. The web server translating a web request to a database call does not remember anything relevant about the transaction. Databases are designed to allow multiple readers and writers to work simultaneously on shared state.
We do not have this luxury in Maya. Maya is not a database and we cannot design as if it were one. When a client asks the server to create a sphere, the client expects the sphere to remain there until the client deletes it. It does not expect the state of the Maya scene to...