Daniel Pitts said:
Often, a event-driven webapp might use Ajax, or Cometd to push/poll
events between the server/client. Also, Spring Web Flow is considered
event-oriented. The actual HTTP request isn't the event, but instead
describes the event (the user clicked on button A, or the user clicked
on button B).
Event-driven is often just a way to explain the information flow
within an application. If you get down to it, all programs are finite-
state Turing machines.
To me, the main difference between event-driven applications and
non-event-driven applications are that with event-driven applications,
when someone asks you to point at the line of code that's currently
executing, it's possible for you to say that there isn't any such line,
that the system is waiting for an event to occur to trigger some
behaviour. E.g. contrast these two pseudocode listings:
Begin Program
Print "What is your name?"
Input $NAME
Print "Hello " + $NAME
End Program
Begin Program
On Key Down $KEY_ID
Begin Subprocedure
Print "You pressed key: " + $KEY_ID
End Subprocedure
On Key Up $KEY_ID
Begin Subprocedure
Print "You released key: " + $KEY_ID
End Subprocedure
End Program
With the first program, even if the program is idly waiting for input,
you can point to the "Input $NAME" line and say "This is the line that's
currently executing", whereas you can't really do the same with the second
program.
Almost every web app I've seen is, in this sense, event-driven. Code
usually runs in response to a visitor requesting some web page. When
there's no visitors, there's no requests, and thus none of your code is
running (the server's code may be running, but I consider the server to be
a distinct application form your web app).
- Oliver