[geeks] Interactive serial terminal programs

[Jonathan C. Patschke]

On Sat, 11 May 2002, James Sharp wrote:

>> Is "dispatch" time-sensitive, or is this just record-keeping?
> 
> Fairly time sensitive.  I'll be storing pre-planned data in there, as
> well as contact information for certain agencies.  It'll also be a
> logging system during a call (i.e. 2134 hours:   Unit 2394 arrived on
> scene).

Okay, but you're not actually going to be dispatching the trucks and such
remotely via this app.  That's what I meant by "time-sensitive".

> May be "retro", but I'm amazed at how many places still use systems
> like this...Especially medical centers, where they can't really deal
> with the downtime necessary to do a migration to a new system.

I never said retro was a bad thing.  In terms of a project like this,
there's no need for anything other than a serial terminal.  Plus, they
sell for cheap these days.

> They'll be replacing them with Windoze machines over my dead body.  Why
> pay $300-$00 for a windoze machine when you can get a terminal for $50.

Precisely, but I couldn't think of anything else that PHP/HTML would gain
you.

> PHP was my first thought, but then when i realized that I'd have to be
> tossing cookies and other stateful information all over the place, it
> made me wanna yack.

This is the hell of "web programming".  I could fill a book with rants and
justifications on why most "web-enabled" services gain nothing from
"web-enablement" and actually lose a -lot- in terms of user interface.

> But as far as driving me certifiably insane, thats about a 2-3 minute
> walk for me.

Well, I think that goes without saying for anyone in network/system
manglement/administration.

> I had panicked a bit when I realized that I would have to basically
> write a whole set of functions for each screen I wanted, but then it
> dawned upon me that I would have to do that even with PHP, so that
> doesn't bug me all that much any more.

"Everything old is new again."

The computer/viewer paradigm of the mainframe era is pretty-much identical
to the "web-enabled" paradigm of today.  Same problems, same
solutions--except for that carrying state around is a PITA since you don't
have true "sessions" in the web world.

>> Open N connections to a server process which manages everything.
>
> I had planned on that...instead of having every function have a whole
> bunch of database code written into it.

Plus, if you ever wanted to switch-out backends or refactor your database
to optimize for some frequently-recurring report, you only have to change
your code in one place.

> Most likely MySQL, unless someone can give me an overwhelming benefit
> of PostgreSQL, since I'm more familiary with the C library of MySQL.

MySQL should be fine for something like this.  Just be sure that you do
backups very frequently and that the server is on a UPS.  I'd go as far as
saying that redundant storage would be nice (RAID 1), but if you have
backups and a UPS, it'll only save you downtime.

PostgreSQL would be nicer for something complicated, but this primarily
sounds like well-indexed record-keeping, instead of fully-relational data
housing/mining.

Plus, if you don't know already ncurses and/or Berkeley sockets, you'll
have enough to wrap your brain around--no need in learning another RDBMS
if you already know one that'll work for something like this.

> And I'm doing my initial development with a couple of VT510s I got very
> recently.

VT510s are -sweet- terminals.  Actually, pretty-much any DEC terminal is
sweet.  I used a Lucent-badged terminal (on a Definity/Intuity system)
just recently that I liked a lot.  I wish I knew who made it.  It kinda
looked like a Relisys, but not as junky.  It even had dual session support
and printing capability.

--Jonathan