Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!umd5!umd5.umd.edu!ziegast From: ziegast@umd5.umd.edu (Eric W. Ziegast) Newsgroups: comp.windows.x Subject: Re: Looking for a program like xtalk... Message-ID: <5369@umd5.umd.edu> Date: 25 Sep 89 02:19:19 GMT References:<58273@aerospace.AERO.ORG> Sender: news@umd5.umd.edu Lines: 60 In article , mende@athos.rutgers.edu (Bob Mende Pie) writes: > Now ... say that the person that you talked is also using a xdisplay. >You talked user@heckle since that is where he is logged in. But little to >your knowledge, his heckle window is closed, and has been for hours. A >normal talk message might go unnoticed. To complicate things, his xdisplay >is jeckle. Thus talkd on heckle has to find out where user's display is, >open either a talk on this display, or open a requestor box on his display. > The requestor box is also simple, the hard part is finding out where his >display is. Where do you get jeckle:0.0 from. The three possibilities are >a) from some magic file (this is loosing for all the obvious reasons) b) >from the users enviorment. Of course this means that talkd has to check to >see if your logged in and then prowl through your enviorment, and hope you >have a display enviorment variable set. c) get it from some other >mechanism that does not yet exist. While c is the best choice, b is the >most likely implementation. > Tbere should be some way to identify where your xdisplay is located. >If people want system services to interact with X, this will have to be >standardized. One problem with this approach is that the receiver has to have their display xhost + to your machine. Due to the fact that X11R3 lacks security except for + or - to a machine, I only xhost + to the hosts that I am actively using. Having your display xhost + to an X hacker can lead to all sorts of nasty things. If some guy out in Alaska (or anywhere) wants to xtalk to me, he can't becuase my display won't let him. Solution: Have the program talk no interaction that requires xhost access. One way thought up around here was to create a daemon on the machine that handles all xtalk requests just like talkd does for talk. The receiver can allow people to call him by typing a command like "xmesg y [-xoptions]" (look familiar?) which will activate a front end process that will pop up a ringer window (like xbiff) and set a flag or something saying that people can talk to them (much like mesg does). Now to call that receiver, all someone has to do is "xtalk receiver@receiver-host". (Note the absense of :0.0) The xtalk pro- gram will send a message to receiver-host's xtalk daemon and let the daemon send a signal to the ringer on receiver's display to make in "ring". At that point, the user can through a response like "xtalk -answer" send a signal back to the caller to have the connection made (At this point win- dows on each one's display controlled by each one's host pop up to talk with.) To make a long story short, recreate the talk program and daemon with each machine having a front-end program to control the display. I have many ideas but not the knowlege to implement them. (So don't ask me for source code. :-) I know enough X to know what you can do and what you can't do, but not enough to program. (Sort of like knowing everything you can make twm do without ever touching or looking at the source code.) If anyone wants to take a shot at this, feel free. I release all copyrights to this idea. Eric W. Ziegast Disclaimers: "uucp!haven!umd5!ziegast".UUCP Any opinions expressed are my own and ziegast@umd5.umd.edu (InterNet) not of any company or institution. ziegast@umdc.BITNET (Bitnet) All opinions are sold "as is." Eric@(301)985-0724 (PhoneNet) No refunds or exchanges accepted.