http://xent.ics.uci.edu/FoRK-archive/apr98/0391.html
Elwood responded:
> I'm amazed by the number of networking people I know who understand
> the necessity for layers of abstraction in the network stack, but who
> don't see a similar need for clear levels of programming abstraction
> in the programming structure, and who chant fashionable 'java...
> c++... object-oriented' tat. Being object-oriented by itself is not
> enough.
Agreed. Elwood, you're brilliant. (You gotta stroke a lot of egos to
make an omelet... :)
Also, joebar responded:
> Threads and events are not mutually exclusive. I'm a strong believer
> in event-driven programming, but there are times where life is just a lot
> simpler when you have two or three threads to play with instead of forcing
> everything into one thread. I am definitely NOT of the religion that events
> should always be waited for separately, one thread per event.
Also agreed. Darn, this Viagra drug is making me totally agreeable.
Yeah, baby! Joebar, you're brilliant, too. (Let it never be said
there's no love on FoRK... :)
Speaking of no love on FoRK, thanks a whole lot Rohit for eating up what
I estimate to be several man-days of work spread among all of us, with
your latest [VOID]post:
http://xent.ics.uci.edu/FoRK-archive/apr98/0414.html
In that piece, Rohit wrote:
> as we were getting ready for the evening, Adam ran into Al Vezza and
> said perhaps ten words ("I'm a friend of Rohit Khare's and I'm finishing
> up a PhD at Caltech on event models") before he all-but offered him a job
This is 100% bona fide true, except that I said 17 words to Al before he
offered me the job, not 10. Al scribbled his email address in my Green Book.
> I brought my laptop; Roy brought Computing Surveys (v17 n4) to read me
> the gripping lede of Tanenbaum and van Renesse's classic: "Distributed
> operating systems have many aspects in common with centralized ones, but
> also differ in certain ways." Also for MsgList: "Another way of
> expressing the same idea is to say that the user views the system as a
> 'virtual uniprocessor', not as a collection of distinct machines. This
> is easier said than done."
Just beautiful. Into the MsgList...
http://www.cs.caltech.edu/~adam/msglist.html
> The difference between requests and notifications: requests are things
> you wait for; notifications are the result of subscribing to an event.
Agreed.
> You can implement both on the same technology same syntax.
This one I'll question mark, for now.
> Events vs messages? An event is a state change, which may or may not emit
> messages.
Sounds like as reasonable a definition as I have ever heard.
Notifications are CAUSAL (that is, IF you subscribe to the polling
service, THEN you will get event notifications) whereas requests are
more CASUAL (that is, IF you want an event, THEN you have to pull it
when you feel like doing so).
Or maybe that's a cutesy but meaningless distinction, like the
distinction Rohit always makes between METADATA and MEATDATA.
> But, in my world, if a tree falls without sending a message,
> it's a nonevent.
I can live with this. It's like the analogy that if a woman finds Rohit
attractive, but he doesn't pay attention and therefore doesn't realize
it, then he's allowed to wallow in his (incorrect) assumption that no
one finds him attractive.
> The implementation choice to block or not block is separate again from
> the expectation of response which differentiates requests (nonresponse
> is an error) and subscriptions (nonresponse is a sign nothing
> happened!). Hmmm.
Right!
> That implies notification requires a strictly more reliable network
> (more powerful abstraction) -- that might torpedo the equivalence
> theory.
My hunch is that it does. But I'm willing to keep an open mind.
> Failure on a physically-connected network is now different from
> across-the-public-internet. Or do we need heartbeats to equivalence the two?
We might, rabbit, we might.
> Debating the quality of Madonna's Ray of Light.
It's her best album, and your nonsequiturs make me want to eat
lampshades.
> Adam has no taste in music... he just buys it.
The additional cost of figuring out whether I want something right away
just isn't worth it. I don't like to rush to judgment. I can sell a CD
used with no love lost, and it usually takes me 10-20 listens to
determine if I like something.
> There's no discernable pattern to what he likes (and he's proud of it).
There IS a discernable pattern, it's just not apparent to the casual
observer. Actually, it's not apparent to the causal observer, either...
So a few more thoughts as to why DOM events (inside a document) and
Internet-scale event notification are similar problems, in my mind.
I've been trying to reconcile whether event passing mechanisms on many
different levels actually do work similarly. I still have a lot to
read.
My intuition is that if we could unify the API for the event models at
several different layers of the application stack -- from the way the
GUI sends event to "documents", to how documents send events among the
components (and scripts) embedded within those documents, to how the
components in documents subscribe to (and notify) the components and
scripts in other documents across the Internet -- well, then we'd have
something truly powerful.
Not necessarily more efficient mind you, but more powerful to
programmers adapting application events to new contexts: sending the
"unitsOnHandChanged" event to a local HTML ticker, to a spreadsheet in
another process on the same machine, or to a database store across the
Internet. My hunch is that by unifying the notification models for
different event sizes and performance requirements, we can simplify the
programming model by abstracting that there are just components and a
bus, and the components themselves can be local or distributed. Then,
as many middleware researchers do, we can focus on intelligently
supporting the kinds of performance constraints and distribution
topologies necessary below this service level.
To be sure, this vision isn't a pachinko machine for distributing opaque
balls-o-bits from event sources to sinks: it relies on a more principled
format for describing data. If events were unified in an XML wrapper,
then perhaps filtering, aggregation, and type conversion make sense as
tree automata transformations. The way a "mouseDown" event percolates
up the stack to become a "sellStock" transaction event in the database
is akin to ascending a Jacob's Ladder of transformations, step by step.
The Document Object Model's event model could be designed in such a way
that it matters not where the "components" of a document really are:
they could be linked to elsewhere from within a document rather than be
explicitly embedded within the document (XML allows this), and the event
model would still work properly even though events must physically
travel over the Internet. Components anywhere could send events to
components anywhere without tunneling or other hacky tricks.
True, the DOM working group has a much more limited horizon: they want
to make Web documents (*ML) interoperate with different scripting
languages. So they're less interested in generic event models as they
are in *specific event sets*: will it be mouseDown or buttonDown? Will
we send pre-peering events (raw) or symbolic events (checkboxTicked)?
What's the right API to an event-driven parser? It may very well be the
case that some variant of SAX will be perfectly sufficient for DOM.
But I foresee a (potential) future where scripts, style sheets, parts of
documents, and processors are completely separated across the public
Internet. In this latency-is-no-longer-a-problem future, the
browser-centered event model will need to be ported to incorporate
decentralized notification protocols.
I would like my thesis to be about the unification of event models, from
low-latency components talking among themselves locally on a client,
through potentially high-latency components communicating with each
other across the Internet. Beyond that, I suppose, anything is game
still.
I still need to read about COM's threading models, as joebar suggested
http://support.microsoft.com/support/kb/articles/Q150/7/77.asp
but that will have to wait for now, as I have like 300 other things I
also need to read.
I want to close with something I'll type in from "Computing Japan"
magazine, April 1998. The munchkins are on their way...
> As routers become less expensive, power users will gradually shift
> from TAs (terminal adaptors) to routers. As a result, some late-start
> TA vendors may abandon in-house development and shift to OEM supplies.
> PHS (personal handyphone system) mode TAs have already been developed,
> February 1998 "PC Wave" magazine notes, but the magazine forecasts
> that PHS and mobile PC's will continue to be merged, producing
> notebook PC's with antennas as well as PHS LAN's and PHS printers.
>
> Peripheral makers and PC vendors will actively support USB (universal
> serial bus), says "PC Wave", logically enabling connections of up to
> 127 USB devices. Most Windows 98 machines will use USB ports with
> PCI-based USB cards. If Windows 98 supports easy use of USB, by early
> 1999 many PC's will be sold without RS-232C and parallel ports and
> PS/2 connectors.
Thanks to Rohit for pointing out this passage. Well, Rohit, you have
your work cut out for you now. Win98 is shipping in two months, and
even Time magazine this week in a fluff piece about Windows 98 is
extolling the virtues of using USB for daisy chaining (daisy chaining
mentioned in Time magazine?? ooooga!!!). Your munchkinnet is coming,
dear Rohit, whether you're on that gravy train or not...
----
adam@cs.caltech.edu
H.H. Goddard in the 1920s coined the word 'moron' to designate 'high
grade' mental defects. Delineating these people by slightly subaverage
scores on primitive IQ tests, Goddard judged them to be more dangerous
than obvious idiots because their gene pool might proliferate. Goddard
favored keeping 'morons' happily segregated in colonies where they could
be prevented from breeding.
-- Jeffrey Klein, Mother Jones magazine, May/June 1998, page 3