I propose to define message-based application interfaces. Based on a definition of standard frames/messages, an interface consists of a set of possible communication behaviors. A behavior may describe that the application
– sends frame X, but does not expect a response.
– receives X, but does not have to respond.
– requests, i.e. sends X and expects a response Y.
– responds, i.e. receives X and sends a Y.
– requests notification, i.e. sends X and receives continuously Y updates.
– notification, i.e. receives X and sends continuously Y updates.
– request notification cancel, i.e. sends this message to stop continuous updates.
– notification cancel, i.e. receives this message and stops continuous updates.
For example, the ‘APPLICATION’ base interface may be
send: (RUN)
responds: (SLEEP, SLEEP_RESPONSE)
responds: (TERMINATE, TERMINATE_RESPONSE)
receive: (STOP)
where RUN, SLEEP, TERMINATE, TERMINATE_RESPONSE, and STOP would be messages with well-defined frame structures in a configuration file. New applications may define new frames and communication behavior. For example, a ‘SHELL_USER’ application may have a defined interface:
sends: (STDIN)
receive: (STDOUT)
receive: (STDERR)
An AUDIO_CONTROL application may be defined as
receives: (VOLUME)
responds: (CONFIGURATION, CONFIGURATION_RESPONSE)
An application may provide a set of interfaces that corresponds to its services and service usages.
Advantages:
– Since all applications would talk to each other over a system bus, communication could be monitored easily.
– Such an approach would allow one to implement environments with dynamic service discoveries. For example an application might ask: “Is there an application that can send SMS?”, the system may respond with the service provider and the requesting application might immediately talk to the SMS sender, because its interface is well defined.
– Applications would live in a tight cage and may not do harm to the system. It would not access anything beyond its cage, except through messages.