Quick note to original poster: IIRC, there are plans to produce articles on this topic. It was one of the things we were discussing pre-GTG and when people started to get really geared up, we were asked to wait for the GTG announcement.
If/when GTG people get the more important things out of the way, and then get on to creating an area for articles on java.net, then there's no shortage of interested authors from this site who have volunteered, IIRC.
I think its just a question of how we use the terms where we differ, not the concepts themselves

Heh, yeah

. "Once a hardware designer, always a hardware designer"? Hmm, maybe

. Well, to me, an "event" is synonomous with an "edge" in hardware design. Both of them are (can be?) defined as being "the moment something changes".
My blinkered perspective is partly coloured by my work with MMOG engines, where event is frequently (and IMHO most usefully, in that area) defined as "any change in any game state any where". In that area, an "event based system" is one where listeners will receive notification of every change, no matter which physical server it occurred on, delivered to their VM. Multi-threading may or may not come into it (except that you are usually talking about a distributed system).
The phrase "-driven" usually IME refers to how you architect the code that is invoked as a result of an event or state-change. If you create self-contained class hierarchies that implement an interface and receive a call to a "notify( event )" method every now and then, AND they do all their processing inside the context of the thread that called the method, then they are being driven by the event.
If, OTOH, the method(s) that are invoked as a result of an event merely store the data of that event, and a separate thread (or same thread, but from a different context) jumps in [ * ] and does something with the data, then it is not being "driven" by the event, it is being "fed" by it. My understanding is that this latter case is how most single-game-loop developers are working? It makes your execution time very deterministic etc (you do very little processing during event-handling, since you have no control over how often or when events will be handled).
[ * - ...and this thread is not being deterministically invoked by the fact that the notify() method was recently called. I.e., usually the events come in at random intervals (e.g. mouseevents, or keyevents), whereas the processing thread comes in 60 times per second, and if there is data pending, does something, if not, it just drops out and goes and does it's other work elsewhere.
EDIT: Correcting YABB's parser problems. You can omit [ list ][ /list ] but it still interprets the [ * ]. Oops.
EDIT2: turning off smileys does NOT stop YABB from parsing [ * ].
