One interesting possibility might be to try and re-work Seaside just a
little bit and build your app around a request/response cycle that's
similar to the way a web app would work.  You would serve a screen full
of VT220 text, and have certain key entry sequences submit a "request",
to which a subsequent screen full of text is served.  If it's a really
really slow connection, this wouldn't be ideal, but if it's reasonably
fast, you could benefit from a lot of re-use of the Seaside framework
(and things that get built on top of Seaside).

As for implementing the VT220 server, I'm thinking you'd only need to
implement a telnet server and spit out VT220 encoded output right?  A
telnet server should be really easy to implement.

- Stephen

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Nevin Pratt
> Sent: Friday, February 14, 2003 11:45 AM
> To: Andrew.Stoffel at jenzabar.net; The general-purpose Squeak 
> developers list
> Subject: Re: End-user accessing Squeak "program" from a VT220 
> terminal?
> 
> 
> 
> 
> 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.
> 
> Nevin
> 
> 
> 
> 
>