I’ve spent the last three hours trying to get my new photo site posted to no avail. Will have to check with the webmaster tomorrow – any page with a code behind throws an exception that I can’t seem to catch or echo to the screen. 😦 I guess I’ll have to build a simple HTML front end in order to post a bunch of new Patrick pictures for my parents.

In other news, Dare’s back from his world wide trip. Looking forward to the new builds of RSS Bandit. But it took him a while to make any sense of my last post in the objects vs. entities discussion. Apparently, I’m not as lucid at 11pm as I thought. Given that it’s 11pm as I write this, here’s my single attempt to make a coherent point.

XML, even with Infoset/XPath 2.0 Data Model/XSD/etc, has it’s roots in a text based format. Attempts to hide this with strongly-typed object-oriented mechanisms will always be leaky abstractions. But that’s OK, since XML actually works for loosely-coupled cross platform services while strongly-typed object-oriented mechanisms only work for tightly-coupled n-tier applications. And I’m out of the application business.

Since I’m going to have to build some XML entities for interoperability purposes, it makes sense to build all my entitles that way, even the ones that are private to my code. This way I have a single architectural model, improve reuse, reduce training, and avoid writing any annoying XML <–> OOP conversion routines.

As if the VS.NET PowerToys weren’t cool enough, now you can join GotDotNet communities and help contribute to their development. Actually, I should say “will be able to help contribute” as all the links the the specific communities are not working yet.

As a bonus, you can get (will be able to get) access to an alpha build of the VSCMDShell Window PowerToy.

I got my blogging front end – built on Front Page – moved over to my new tablet. I wrote at least part of this entry in ink. I was surprised to discover that Office 2003 does not include the Office Web Services Toolkit functionality, so I had to install that separately. While I was at it, I downloaded the VS.NET Tools for Office. I was thinking of writing a C# based blogging front end that used Word instead of Front Page or InfoPath since only Word supports the Text Services Framework. This means that if the tablet mis-recognizes your handwriting, you can choose alternative recognition options instead of deleting and rewriting the word. For pen based input (with my crappy handwriting) this is a huge time saver.

After introducing myself at a customer meeting today in Phoenix, someone asked “Are you the Harry Pierson from DevHawk?”. First time that’s happened – kinda cool. Nice that he recognized my real name – I think most people who read this blog just know me as “DevHawk”. A couple of times, I’ve introduced myself to blank stares then mention that I write DevHawk to instant recognititon.

BTW, I did take the plunge and put the URL for my blog on my business cards.

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>