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.