End-user accessing Squeak "program" from a VT220 terminal?

Nevin Pratt nevin at smalltalkpro.com
Fri Feb 14 16:45:06 UTC 2003

Andy Stoffel wrote:

>And then there's the classic... have them use a text based web browser
>(Lynx) on the machine they are connecting to and do your application as
>a web application.... more or less.
>Note: I would love to see how you actually do this if you don't go
>the html route... :-).... 

The idea is to provide a foundation that allows them to migrate away 
from an archaic technology (Ingres 4GL) to a more modern technology 
(Squeak).  For business "benefit vs. cost reasons", the migration would 
have to occur a piece at a time.  Therefore, the end-user sitting at 
their VT220 wouldn't know from one screen to the next whether that 
screen (or even portion of a screen) is being serviced from Squeak code, 
or from Ingres 4GL code.

(For those not familiar with Ingres 4GL, it is "yet another procedural 
language"--YAPL--that happens to allow embedded SQL code, and that does 
NOT have a debugger, and the YAPL is completely proprietary.  There's 
really nothing *at all* special about it, or powerful about it, or easy 
about it, or in any way satisfies or meets the expectation that you 
might expect from a so-called "4GL" moniker.  It's coding metaphor is: 
"lets attach these procedural cursor-oriented field triggers to these 
particular screen fields, and then create the business logic within the 
field triggers, and we'll duplicate this mess on every screen".  That's 
it.  Makes you wonder how they ever sold this crap to *anybody*, or why 
anybody would have bought into it in the first place)

Anyway, I envision that at first for this project, that all of the 
communications from the VT220 terminal would be directed to the Squeak 
image, which would then subsequently just "pass through" everything to 
the Ingres 4GL program.  The Ingres 4GL program would think it was 
talking to a VT220 terminal, when in reality it would be talking to 
Squeak (this part could be done with the telnet client in Squeak).  Then 
Squeak would pass the reply from the Ingres 4GL program back to the 
VT220 terminal that the end-user is sitting at.  Thus, at first this 
would look EXACTLY like Squeak wasn't there, when in reality it would be 
sitting right in the middle of it all.

Then, one little piece at a time, Squeak code could be written to 
replace the Ingres 4GL functionality, and without impacting the end-user 
at any time.

Initially all of the end-user "enhancement" requests would be satisfied 
via Squeak code rather than Ingres 4GL code.  Then over time, pieces of 
the Ingres 4GL code would be phased out, until eventually Ingres 4GL 
wasn't needed.

Given this scenario, it doesn't readily appear that a text based web 
browser would fill the bill (unless I'm missing something).

Anybody got any other ideas?

Oh, yea, another piece of info: I think I could entice the Ingres 4GL 
code to work satisfactorily thinking it was talking to a VT100 terminal 
rather than a VT220.


More information about the Squeak-dev mailing list