From: utzoo!decvax!ucbvax!info-vax Newsgroups: fa.info-vax Title: Communication between users Article-I.D.: ucbvax.8022 Posted: Thu Jul 15 21:19:34 1982 Received: Mon Jul 19 04:35:41 1982 >From FONER@MIT-AI Thu Jul 15 21:17:21 1982 Since you specify that multiple (more than two) users may be present in the link, having the originating user create a mailbox for communication is pretty clearly not the way to go, as everybody suffers when s/he leaves (and there are sufficient conditions for races unless some algorithm is employed to prevent them when each of the remaining users tries to initiate communication using a mailbox each one starts). Using a global mailbox for communication has some advantages. Each user could specify the name of the same mailbox, thus identifying which of possibly several multi-user links s/he wants to participate in. Note that this avoids a pathological case in which a user manages to link two or more formerly separate multiuser links (though this could occasionally be what is desired, I doubt it). Such a program could be installed with sufficient privilege to create global mailboxes. The method generalizes nicely to the case where you have links across networks, using DECnet, in that the program may be given NETMBX. Alternately, your idea of a hibernating process sounds interesting. Given that there must be some way of differentiating two separate simultaneous conversations anyway, one such process could handle every link in operation, meaning that you have as overhead only one process no matter how many users are talking and no matter how many separate conversation are going on. Again, extending this to DECnet is easy. If you plan on having the conversation look something like ITS UNTALK (in which each user gets a portion of the screen so that each may type simultaneously with no mixups), you'll have to be terminal-independent unless your installation uses all the same type of terminal. You could use a TERMCAP-type of system, if one already exists for VMS (I don't know), or build something under Gosling's EMACS for VMS, if possible, using EMACS to handle terminal-independence (by simply having the communications process update the buffer and then asking EMACS to update its representation of the buffer---such subroutines are probably accessible, but I've never done that sort of thing under EMACS, and the last one I've touched is now a year old at least). Let me know what you come up with. I'm sure that many others besides me would be interested in such a program... I don't think such a program exists for VMS, since CHAT allows only two users (using the mailbox idea where the originator creates the mailbox and the "slave" dies when the mailbox does). Ciao.