Jeff Davis wrote:
From my
programmer's point of view, it was an event driven system - I called a
library
routine to register that my routine X handled a particular client
token. When a user clicked a button on a form, it would send down a specific
token and some data, which the front-end layers would decode, check it's token
table to see who handled it, then call the handler and pass the data. The
handler routine would do something, then send back to the client another token
and data. There were a lot of system routines in between me and the client
that would take care of formatting and sending the data to and from the
client.
QLink does not appear to use FDO (AOL speak). I had considered using an
event model (register for the token of interest, when it arrives, call
the handler), but there is an order and state to things as well.
When you first log on, you must send a D3, client sends D6, you send DO,
etc. FOr a dialog box, you send ZM, it sends ZO, you send ZT ZT ZT ZQ,
it sends ZA, etc. So, there is an order to things required. IN
steady-state, I can see where just calling registered handlers would
work, but not sure when the system is in steady state.
Jim
--
Jim Brain, Brain Innovations
brain at
jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!