End-user accessing Squeak "program" from a VT220 terminal?
spair at acm.org
Fri Feb 14 16:58:52 UTC 2003
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.
> -----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
> 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
> 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
> 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