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.