I watched Don’s MSDN TV
talk
on passing XML around within a managed application. The value of
XPathNavigaor has been discussed in
blogsphere,
but it was nice to see it explained by the master.
<nostalgicMusic action=”cue”>
It reminded my of one of my first encounters with Don. I was a recent
addition to MCS in
SoCal and we were having a team meeting / training at
DevelopMentor. Among other speakers, Don was
scheduled to discuss the then-brand-new SOAP spec. As is expected with
Don, the presentation started with thirty minutes of “look what cool
code I whipped up at 3am this morning”. In this case, the code was a COM
based SAX parser based on
expat. In his implementation,
Don had mirrored the SAX API exactly, including providing the
setXxxHandler methods. I asked him why he hadn’t used COM
Events.
He commented that I had really drunk the kool-aid and that was the end
of it.
Personally, I hate registration API’s like SAX’s setXxxHandler methods.
While COM Events has a lot of plumbing overhead to get nailed up, but
the benefit was that it provided a late bound mechanism for locating
event sources. Using registration API’s like setXxxHandler means having
to redefine your interface to support new event types. Of course, CLR
delegates, the pull model XmlReader and XPathNavigator have made the
registration API vs. COM events discussion moot.
Interesting follow up to this story: I ran into Don at an internal event
last November. He couldn’t remember my name, but he remembered the event
at DM and that I was the one who asked about that COM events stuff.
</nostalgicMusic>