From owner-freebsd-current Sun Mar 24 13:59:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26866 for current-outgoing; Sun, 24 Mar 1996 13:59:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26859 for ; Sun, 24 Mar 1996 13:58:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA10350; Sun, 24 Mar 1996 14:51:10 -0700 From: Terry Lambert Message-Id: <199603242151.OAA10350@phaeton.artisoft.com> Subject: Re: Patch to talkd To: imp@village.org (Warner Losh) Date: Sun, 24 Mar 1996 14:51:10 -0700 (MST) Cc: jkh@time.cdrom.com, freebsd-current@FreeBSD.org In-Reply-To: <199603242032.NAA00256@rover.village.org> from "Warner Losh" at Mar 24, 96 01:32:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > : If I don't like talk requests, I can always mesg n in my elm window, > : after all! :) > > Personally, I'd rather be able to create a unix socket named, say, > /var/talk/imp and have talkd tell that file that I have a talk > request. Makes writing a talk client that automatically pops up when > a talk request comes in much easier.... > > However, the current patches are better than nothing. This is part of the larger problem of "how do I deal with broadcasts in a logical way". The utility of broadcasts is severely restricted under UNIX because of the presentation mechanisms available. VMS was able to kludge this by insisting on ANSI escape sequence based terminals (really, they insisted on a tiny subset of even ANSI termials) so that they could block further I/O from the main channel in order to handle the broadcasts, and they could block the broadcasts until the finite state automaton showed a ground state (ie: no interrrupted or partial escape sequences). This hadn't been a really a good option under UNIX until X became somewhat pervasive. Even now, it isn't as pervasive as you'd like. If you plan on hacking any of this, rather than following in the footsteps of VMS, you'd be better off working on divorcing the concept of session from the concept of tty, and establishing per session broadcast channels. By default, a session bound to a tty would register to recieve broadcasts in the tty data stream. This would be a function of the getty/telnetd/rlogin programs, since it's at that level that the association of session to broadcast channel and broadcast channel to tty must occur. This would establish historical behaviour for the default session applications that come with FreeBSD. You would need to hack xconsole, xterm, etc. in a FreeBSD specific way to clean up the other interfaces. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.