home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: alt.bbs
- Path: sparky!uunet!murphy!jpradley!magpie!manes
- From: manes@magpie.nycenet.edu (Steve Manes)
- Subject: Re: GIF Menus on BBSs
- Organization: Manes and Associates, NYC
- Date: Wed, 27 Jan 1993 03:29:22 GMT
- Message-ID: <C1Htoz.2Fs@magpie.nycenet.edu>
- X-Newsreader: TIN [version 1.1 PL8]
- References: <h0k3p!q@rpi.edu>
- Lines: 29
-
- Paul Jason Clegg (cleggp@aix.rpi.edu) wrote:
- : GIF MENUS!
-
- : Yes, I know to transfer the menu everytime would take forever, particularly
- : at the slower speeds. But, why not do something like this:
-
- : It's a given that a special term program will have to be written to allow
- : for graphics to begin with. What the term program would do, however, is
- : receive a VERY short code from the remote host, perhaps a filename and a
- : date. It would check to see if it has the filename (which would be the GIF
- : file) and check it's date to make sure it's current. If these were not
- : true (ie no file or older file), the board (or term program) would prompt
- : the user if they wanted to d/l the new menu, and then (if yes) run a ZModem
- : (or some protocol) download of the proper menu. BUT it would keep the menu
- : on the user's harddrive, so the user wouldn't have to d/l the menu everytime.
- : Once the menus are d/led, the display time for a menu would only be limited
- : by the user's computer system, and not the comm rate. Of course, the board
- : would also allow ANSI/ASCII logons as well, and volatile information (file
- : dirs, messages) would still have to be transferred by normal means.
-
- That's pretty much the way these things work. When I was working on
- Citibank's Enhanced Telephone (an extension of their Direct Access
- home banking system) that's how we kept menus current.
-
- Unfortunately, Citibank's ET is long dead.
- --
- Stephen Manes manes@magpie.nycenet.edu
- Manes and Associates/Commontech-NoHo New York, NY, USA =o&>o
-
-