Re: [MUD-Dev] Re: Multi-threaded mudding (was a flamefest)

[Jeff Kesselman <jeffk#tenetwork,com>]

At 08:16 AM 5/3/97 PST8PDT, you wrote: 
>>>>
> This application relies on the OS to generate all its events.
> More particularly the socket port and the system clock.
> All applications that run on a Unix machine would then 
> classify as event driven taken collectively together as
> a system.  Clearly not the intent of the distinction between
> procedural and event driven.
<<<<

::sigh::

Okay. First off COld does NOt generate these events off the OS. In point of fact cold has an inetrnal processing loop that polls the various OS sources and 
converts the results to events as needed BUT this is an implementatio ndetail and totally irellevent.

The definition of event driven code is really very specuific, precise, and has ntohing whatsoever to do with OS v. Application.

The MacInstosh and Amiga are 2 classic systems that program i nan event driven model (Windows is a third, though overly complex and thus a bad example case.)

The fundemental difference between the two models is that a standrad procedural program queries for input and blocks until it recieves it, then movign on. In thsic ase the flow of control is driven by the procvedural code.

In contrast an event driven program registers a set of call-backs on various input events with a central dispartch mechanism (be that OS OR application code).  Code is then dispatched as the central loop senses input events ocurring. In this model the flow oc tronl is dribven by the suer events, thus the term "event driven."

At Philips we built a totally event driven system for CD-I development that was ALL application code as a set of libraries.  

This is the definition of the term. IMO if this is not what you are talking about you probably need to coin a new term rather then over-loading an old one.

Jeff Kesselman