[Complete Newbie Response] Re: End-user accessing Squeak"program"
from a VT220 terminal?
nevin at smalltalkpro.com
Fri Feb 14 18:37:37 UTC 2003
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
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.
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
> 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)?
More information about the Squeak-dev