Date: Sun, 24 Mar 1996 15:05:24 -0700 From: Warner Losh <imp@village.org> To: Terry Lambert <terry@lambert.org> Cc: jkh@time.cdrom.com, freebsd-current@FreeBSD.org Subject: Re: Patch to talkd Message-ID: <199603242205.PAA06839@rover.village.org> In-Reply-To: Your message of Sun, 24 Mar 1996 14:51:10 MST
next in thread | raw e-mail | index | archive | help
: 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). Actually, are you sure about that? The broadcast mechanism was supposed to let the current write to the terminal complete before broadcasting. However, users could setup a mailbox to receive the broadcast messages. I don't think that if you were to, for example, write out 3 (of say 6) characters of an escape sequence in one QIO and then the last three in another that the driver would prevent a broadcast message from getting splatted out between the two. I never saw that in the docs.... : 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. That's kinda what I was thinking, but more of a per user thing rather than a per session one. Talk doesn't have a good way to say "talk to the person that is sitting at X display :2" : 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. Ick. I don't want to hack the kernel just so that I can get talk requests forwarded to me. I can think of three ways to do it: 1) Use a unix domain socket that is bound to the filesystem. Talkd stats that file and if it is acceptible, sends me the message. 2) Connect via TCP to the talk daemon and use a different request number that says "Oh, if you get a talk request for user xyzzy, please be a dear and forward it to me at this address" 3) Have talk connect to my X server, write a property on the root. My X-based talk client would then be able to get PropertyNotify and I can do the reply. None of
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603242205.PAA06839>