Re: More on events. Also: the munchkins are coming!

Mark Baker (
Wed, 29 Apr 1998 15:36:20 -0400

At 11:40 AM 29/4/98 -0700, I Find Karma wrote:
>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.

No shit Sherlock. 8-)

It's very component-centric (vs. document-centric), but the message is
identical. No surprise there.

>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:

Beware transparency. But you knew that.

>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.

So how would an "actuate=auto" link work if only part of the linked
document is retrieved? What's a script in the document containing that
link to do, when the full document isn't retrieved? How will it know it's
not the full document? Waldo still counts in the world of documents.

>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.

SAX rules.

I just started a SAX compliant iCalendar
( parser.
XML?! We don't need no stinkin' XML! 8-)


Mark Baker.               CTO, Beduin Communications Corp
Ottawa, Ontario, CANADA