Date: Sun, 24 Mar 1996 15:21:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imp@village.org (Warner Losh) Cc: terry@lambert.org, jkh@time.cdrom.com, freebsd-current@FreeBSD.org Subject: Re: Patch to talkd Message-ID: <199603242221.PAA10414@phaeton.artisoft.com> In-Reply-To: <199603242205.PAA06839@rover.village.org> from "Warner Losh" at Mar 24, 96 03:05:24 pm
next in thread | previous 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.... Of course not. You are not supposed to write out incomplete ANSI escape sequences using QIO's; you are supposed to use the terminal interface to do it (which doesn't let you write out incomplete sequences, period). The ternial interface notifies the device of changes in insert/overstrike mode, scroll regions, and other issues which may impact the ability to switch sessions or print transparently, etc.. The finite state automaton I was referring to above is the one in the terminal itself. This is somewhat confusing, since the input mechanism under VMS is designed to undraw/redraw the current partial input line (it has *another* automaton -- which is why later DEC terminals do not have an Escape key). LAT utilizes this fact for multiple session on VT 330/340/etc. terminal to implement page flipping for things like insert mode for multiple sessions. The main impediment to a status line (typical use for a broadcast mailbox was to stick the broadcasts on the terminal status line) for UNIX is that escape sequences under UNIX are not guaranteed to be atomic (when there are multiple writers to the same tty interface, and the write buffer is large, even changes to all the programs to ensure write(2)-level atomicity won't fix the problem). This is the same reason "transparent printing" is generally such a kludge on UNIX systems. > : 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" A session is a connection between the computer and the user. There is *one* sesssion (in the divorced session model) which represents this. The only exception is for programs from different authentication instances (authentication needs to be divorced from the process and associated -- by default, anyway -- with the session, as well). So a session isn't really connected with the idea "X session" except in a vague, "these-are-the-default-associations" kind of way. > : 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. Well, if you want a non-talk-specific, non-kludge soloution (which you may not 8-)), then you should consider everying in the class with talkd "broadcasts" in the same design. This would include biff, wall, syslogd, write, shutdown, etc., and not just talkd. If you're careful at the same time, you buy the ability to handle things like "transparent print" and "status line support", assuming you make sure curses is clean (writes sequences using one write) and the tty code is sane (doesn't interleave fragmented writes from multiple sources), and that other applications are "well behaved". Realize that crap like Microsoft's BASIC for SCO Xenix/UNIX violates the "well behaved" stricture... 8-(. 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?199603242221.PAA10414>