At a high level, Impulse needs a unified communication system to allow the various components (which have been broadly termed 'managers' up to now) to interact in a sensible manner. Making the interface as abstract as possible is a desirable design goal, as it fits in with ROWS current abstraction interface to an underlying graphics system and sanitises the morass of communication protocols that there are to choose from.
Additional desirable features are: RISC OS-like connectionless interface, the ability to use specific communication protocols with old software, the ability to abstract higher-level communication functions.
My current thinking is not ultimately connectionless, but biased towards CCS-style message queues, giving consistancy betweeen inter-thread communications and inter-process communications. I believe there are three entities required to instantiate a communication: a process identifier (remembering that the process may be on other machines), a communications channel between two processes, and a set of message queues attached to that channel.
A listening process (any running process that supports the protocol) is contacted via whatever standard interface the environment allows (X's ICCM for the moment), using a suitable process handle. A suitable protocol is negotiated (by the comms library), and a common channel is established. The task may be notified of the establishment of the channel, and may want to disconnect straight away, refusing communication. Once a channel is in existance, either task may create a message queue using that channel, which it sends to, and the other task reads from. Message queue creation is notified, as is message reception, and two-way communications take the form of two seperate message queues. Both message queues and communications channels may have an identifier that defines their purpose, to disambiguate different protocols.
In the generic model, messages are of any length and may contain anything, although it is strongly recommended that they conform to a standard style with headers and body. I would like there to be a capability for a task to force an acknowledgement on a message, as in RISC OS, but I think that this is not sensibly possible in a pre-emtively multitasked system (how do you distinguish between a dead task and a slow task?)
In addition, there is a special-purpose message system that allows communication using specific protocols. It is with this in mind that I distinguished channels & message queues (as, for example, a socket has both UDP and TCP connections associated with it, two message queues [well, four - input & output], 1 channel). Note that this system is not restricted to low-level protocols like TCP/IP (which is most likely the most common protocol to be used this way), but can also be used to great effect with higher-level protocols like the font manager protocol, providing an abstract description of the model of communication used between applications & managers.
Note that the special-purpose messaging system is special purpose throughout - you need not use the standard message structure, or contact a process using the relevant ID - contact method and message structure is left up to the implementation layer that actually describes the special-purpose protocol. Uniformity must exist in the generic system, though, as the application has no way of knowing which base protocol is being used.
Finally, have a look at ROWScomm.h if you want to get an idea of how I propose to name the functions and data types.