[geeks] Interactive serial terminal programs

[James Sharp]

> On Fri, 10 May 2002, James Sharp wrote:
> 
> > So I'm going to be writing a rather large application for my fire
> > department...including dispatch, training records, fire incident records
> > and equipment maintenance.
> 
> 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).

> 
> > Since I've got myself a couple of multiport serial boards and a few
> > serial terminals, I was planning on doing it as a character-based
> > application.
> 
> Sounds excellent.  Very retro, but a great use of older technology.

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.

> 
> > 1) Write everything in php, run a local web server tied into the
> > database engine...create a dummy account that spawns lynx as its login
> > shell.  Use lynx to front end those php pages.
> 
> Blech!  Eccch!  Hurp!
> 
> The only benefit I see to this approach is that you wouldn't have to
> recode if someone replaced all your terminals with winders boxen that
> didn't have access to a decent telnet/ssh program.

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.

> 
> You -don't- want to build a big application in PHP.  It will drive you
> certifiably insane.  PHP is ugly shit that is "just ugly enough" for "web
> development" but it's inconsistencies, sloth, and memory bloat will kick
> your ass on anything large and interactive, especially if you're going to
> be carrying any sort of state around.

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.  But as far as driving me certifiably insane, thats about a 2-3 minute walk for me.

> 
> > 2) Write the program in C and use the ncurses/forms library to handle
> >    display formatting.
> 
> This is the Right Thing to do.  ncurses is refreshingly easy to use, plus
> you can do -real- page/form layout without having to get creative with
> lynxish HTML.

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.

> 
> However, keep the client/server model in-place.  Don't open N connections
> to your data store.  Open N connections to a server process which manages
> everything.  This lets you do enforce certain types of coherency with
> ease.

I had planned on that...instead of having every function have a whole bunch of database code written into it.

> 
> > Any other ideas or suggestions?  Preferably something Open Source...I'm
> > running on a limited budget here.
> 
> ncurses, plain ol' TCP running over IP, PostgreSQL.  And don't skimp on
> the terminals, if possible.  Get nice DECs or IBMs.
> 

Most likely MySQL, unless someone can give me an overwhelming benefit of PostgreSQL, since I'm more familiary with the C library of MySQL.  And I'm doing my initial development with a couple of VT510s I got very recently.