Date: Sun, 24 Mar 1996 14:51:10 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imp@village.org (Warner Losh) Cc: jkh@time.cdrom.com, freebsd-current@FreeBSD.org Subject: Re: Patch to talkd Message-ID: <199603242151.OAA10350@phaeton.artisoft.com> In-Reply-To: <199603242032.NAA00256@rover.village.org> from "Warner Losh" at Mar 24, 96 01:32:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603242151.OAA10350>