Improve IPC terminology

[Martin Decky]

It has been suggested multiple times (several times by Petr Tuma) that HelenOS-specific IPC terminology is somewhat strange in that sense that it uses unusual terms for common concepts. Therefore I suggest to gradually replace our specific terminology by usual one, somewhat in the line of:

phone = connection
call = message
reply = response (reply is still OK)
answerbox = message queue (mailbox)

If there is a good reason why we should prefer to stick to your current terminology, please elaborate.

[Jakub Jermář]

Frankly, I don't like the suggested idea for the following reasons:

• the new names are not 100% equivalent with the old ones.
  • A phone should not be confused with a connection, because at best it is only one end of the connection and answerbox_t is the other one.
  • The phone structure usually survives the connection and lingers in the hung-up state for some time or it may never be connected
  • It may even be slammed while the client is still attempting to 'make some calls' over it, so there is a phone, but the connection is gone
  • When you say that task A has a connection to task B, it is not as descriptive as saying that there are five open phones from A to B
  • An answerbox is a collection of message queues rather than a single message queue (or using the term message queue would be confusing too).
  • Neither mailbox is a good metaphor because it lacks the FIFO characteristics
• I perceive it like that our names: phone_t, answerbox_t, call_t etc. denote concrete implementation of concepts of connections, message queues and messages and can be explained or clarified using the standard terms
• I am already familiar with the terminology and by giving it up, HelenOS would lose a bit of its uniqueness
• The weakest chain in the terminology is probably call, but when one realizes that it is a call recorded by the answerbox, its use is IMHO justified
  • async framework uses the term message for a higher level construct based on calls, so it is already taken
• I don't believe that phone, call and answerbox is such a big problem for anybody who has at least a theoretical chance of understanding the rest of HelenOS source code or its architecture

[Jakub Jermář]

I can also see one additional advantage to using non-conventional names for the concept of connection, message and mailbox - out of box thinking. That is, if we use a similar, but still different metaphor for the three than anyone else does, we may be looking at the thing from a different perspective and thus have some potential of brining new solutions to some of the classical problems.

[Jakub Jermář]

The suggested terminology is not being used even in the archetypal Mach microkernel:

(send) right ⇒ connection
port ⇒ message queue

[Jakub Jermář]

Under the weight of the above evidence, I am proceeding to closing this ticket as worksforme. If you disagree, feel free to provide further evidence and reopen.