Q: On a Unix box, what is the name of the daemon that handles the 
terminals?  Isn't that the 'getty' daemon?  I'll assume it is as I write...

I did some more checking.  Seems that, from the point of view of the 
Unix box, the VT220/VT100 terminals for this application are normal 
terminals handled by getty (or whatever daemon it is).  Thus, the 
end-user initially gets a normal Unix logon prompt.  Then when they log 
in, they get a normal csh prompt (because their account as specified in 
'/etc/passwd' says to give them a csh prompt).  Then from their csh 
prompt, they run their Ingres 4GL program.

OK, I tried a minor variation:  instead of running their Ingres 4GL 
program from the csh prompt, I typed 'telnet localhost' (thus connecting 
to port 23) from their csh prompt.  Seems they *do* have a telnet server 
running, because doing this produced the standard telnet unix logon 
dialog.  So I logged on again, and got a (yet-another) csh prompt.  Then 
I ran their 4GL program from this second csh prompt, and everything 
worked fine.

Hmmm, this gets me thinking.  How about this scenario:

They disable their telnet server, and let Squeak create a normal TCP/IP 
connection to port 23 using Commanche to listen to port 23 instead of 
port 80.  When Commanche detects a connection request, it of course will 
spawn a separate Smalltalk thread to service the request.  In that 
thread, I start up a Telnet session (using the Telnet package on 
SqueakMap from Ian Piumarta), and pass everything coming into Commanche 
over to the Telnet session.  Then anything coming back from the Telnet 
session is just replied to the caller over Commanche.

Oh, wait a minute, Commanche will try to package that reply in the usual 
http wrappers.  Hmmm, OK, so I can't use Commanche.

Well, there's the  client/server code that Chris Muller posted about 10 
days ago (see thread "[ANN] Ma client server").  It looks like it 
shouldn't be hard to use it to write a small server that listens to port 
23 and shuttles data between that port and Ian's Telnet client code. 
 Yea, I think that would do it.  The end-user wouldn't know that Squeak 
got inserted in the middle of their data stream (between their terminal 
and their existing Ingres 4GL program), and it would then put Squeak in 
a position to start "influencing" that data stream.

That's what I am thinking.  But as usual, I welcome any other comments 
from other folks.

Thanks,

Nevin


Jack Johnson wrote:

> Nevin Pratt wrote:
>
>>> As for connecting Squeak to a serial port, which as you say must be 
>>> polled, another idea comes to mind:  write a small C program that 
>>> talks to the telnet port, and then turns around and talks to Squeak 
>>> via TCP/IP.
>>
>> Err, I meant "that talks to the serial port"
>
>
> Just off the top of my head, there are a couple of packages in 
> existence already, Telnet and CommandShell, that might come in handy.
>
> Essentially, the info coming from the terminal could be considered 
> events.  You could buffer/echo text coming from the terminal until a 
> CR, and then have Squeak process the contents of the buffer as a 
> discrete message.  The screen draw/refresh on the other end could be 
> handled by a set of primitives that do the VT100 escape sequences 
> (which should all be in the Telnet client already), so you wouldn't 
> have to transmit full screen updates.  Tabs and menu selection (if 
> they're pre-existing in the software you're trying to replace or 
> mimic) could be handled by pre-selecting certain events -- namely tabs 
> -- to manage changing the selected fields, but ultimately it would 
> still be event driven rather than a strict oldschool I/O 
> call-and-response kind of scenario.
>
> Plus, if you write it well, you'll only have to change the UI events 
> when you move away from the terminals (though if your data people are 
> oldschool, I think terminals can be faster -- tab, tab, x, enter 
> without bothering to read or target with a cursor).
>
> If you need a kludge to connect your code into your terminal, snag the 
> telnet code and dangle your terminal from a Unixlike box, and then use 
> some thing like cu, tip or C-Kermit to manage the telnet-to-serial 
> connection:
>
> http://groups.google.com/groups?selm=Windows-Modem-Sharing.1-7902.890796788%40cc.gatech.edu&oe=UTF-8&output=gplain 
>
>
> Or, preferably, run the VM on the same box so you can secure the 
> traffic to and from the terminal.  Has anyone run Squeak under VNC 
> (Unix-native, not Squeak-native)?
>
> -Jack
>
>
>