Scott Hanselman

My eighteenth nineteenth Podcast is up. This episode is all about BitTorrent and TVRSS.

We're listed in the iTunes Podcast Directory, so I encourage you to subscribe with a single click (two in Firefox) with the button below. For those of you on slower connections there are lo-fi and torrent-based versions as well.

Our sponsors are CodeSmith Tools, PeterBlum and the .NET Dev Journal. There's a $100 off CodeSmith coupon for Hanselminutes listeners - it's coupon code HM100. Spread the word, now's the time to buy.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

• Each show will include a number of links, and all those links will be posted along with the show on the site. There were a number of sites mentioned in this episode, some planned, some not.
• The basic MP3 feed is here, and the iPod friendly one is here. There's a number of other ways you can get it (streaming, straight download, etc) that are all up on the site just below the fold. I use iTunes, myself, to listen to most podcasts, but I also use FeedDemon and it's built in support.
  • Some other clients are Doppler (also suppose Windows CE), FireAnt, Nimiq, and PrimeTime Podcast.
• Note that for now, because of bandwidth constraints, the feeds always have just the current show. If you want to get an old show (and because many Podcasting Clients aren't smart enough to not download the file more than once) you can always find them at http://www.hanselminutes.com.
• I have, and will, also include the enclosures to this feed you're reading, so if you're already subscribed to ComputerZen and you're not interested in cluttering your life with another feed, you have the choice to get the 'cast as well.
• If there's a topic you'd like to hear, perhaps one that is better spoken than presented on a blog, or a great tool you can't live without, contact me and I'll get it in the queue!

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Z is six months old today. He's sitting up, sleeping from 8 to 8, eating bananas, rolling all over the place and his mouth is open (as seen below) nearly 24 hours a day. We stopped reading the books that give measurements and tests, but we figure he's where he's supposed to be - he's happy at the very least. He's one jolly fellow.

Things we've learned in the last six months

• Babies that can't walk CAN leap off beds head-first and stick the landing.
• Breastfed Baby poop is cute; Solid-fed Baby poop less so.
• Everyone has an opinion and only yours matters.
• If you're a geek folks will assume your infant has a laptop and a blackberry even if you want him to be the outdoorsman you aren't. You'll find out who knows you and who doesn't at this point.
• Your wife is always cold and you're always hot, and she'll transfer her temperature paranoia to the baby, who will be bundled in a large blanket in the sweltering heat. "He's nippy!"
• Babies don't respect national holidays, nor do they appreciate sleeping in.
• Digital cameras were made for babies.
• You think you love you wife when you marry her. Then you have a baby and you realize you'd throw your wife yourself under a bus to save your baby. You can't love something more.

Pics of the ongoing saga are always at http://www.flickr.com/photos/computerzen/.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

My seventeenth eighteenth Podcast is up. This episode is all about LifeHacking.

We're listed in the iTunes Podcast Directory, so I encourage you to subscribe with a single click (two in Firefox) with the button below. For those of you on slower connections there are lo-fi and torrent-based versions as well.

Our sponsors are PeterBlum and the .NET Dev Journal.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

• Each show will include a number of links, and all those links will be posted along with the show on the site. There were a number of sites mentioned in this episode, some planned, some not.
• The basic MP3 feed is here, and the iPod friendly one is here. There's a number of other ways you can get it (streaming, straight download, etc) that are all up on the site just below the fold. I use iTunes, myself, to listen to most podcasts, but I also use FeedDemon and it's built in support.
  • Some other clients are Doppler (also suppose Windows CE), FireAnt, Nimiq, and PrimeTime Podcast.
• Note that for now, because of bandwidth constraints, the feeds always have just the current show. If you want to get an old show (and because many Podcasting Clients aren't smart enough to not download the file more than once) you can always find them at http://www.hanselminutes.com.
• I have, and will, also include the enclosures to this feed you're reading, so if you're already subscribed to ComputerZen and you're not interested in cluttering your life with another feed, you have the choice to get the 'cast as well.
• If there's a topic you'd like to hear, perhaps one that is better spoken than presented on a blog, or a great tool you can't live without, contact me and I'll get it in the queue!

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Dan Maharry is/was having a heck of a time with the XmlSerializer after upgrading an application from .NET 1.1 to .NET 2.0.

Given this XSD/schema:

<element name="epp" type="epp:eppType" />
<complexType name="eppType">
  <choice>
    <element name="hello" />
    <element name="greeting" type="epp:greetingType" />
  </choice>
</complexType>

The .NET 1.1 framework serializes a greeting element thusly (actually by incorrect and lucky behavior in the 1.x serializer):

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <greeting>
    <svID>Test</svID>
    <svDate>2006-05-04T11:01:58.1Z</svDate>
  </greeting>
</epp>

but although it seemed to be fine initially in .NET 2.0, he started getting this instead.

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <hello d2p1:type="greetingType" xmlns:d2p1="http://www.w3.org/2001/XMLSchema-instance">
    <SvID>Test</SvID>
    <svDate>2006-05-04T10:55:07.9Z</svDate>
  </hello>
</epp>

Dan worked with MS Support and filed a bug in the Product Feedback labs and attached an example if you'd like to download it.

Unfortunately, this isn't a bug. The problem is caused by the ordering of the elements in the original schema causing the XmlElement attributes to stack in the same order resulting in the wrong semantics:

   [System.Xml.Serialization.XmlTypeAttribute(Namespace = "urn:ietf:params:xml:ns:epp-1.0", TypeName = "eppType")]
   [System.Xml.Serialization.XmlRootAttribute("epp", Namespace = "urn:ietf:params:xml:ns:epp-1.0", IsNullable = false)]
   public class EppType
   {
      private object item;

      [System.Xml.Serialization.XmlElementAttribute("hello", typeof(object))]
      [System.Xml.Serialization.XmlElementAttribute("greeting", typeof(GreetingType))]
      public object Item
      {
         get
         {
            return this.item;
         }
         set
         {
            this.item = value;
         }
      }
   }

The problem is that the semantics of the schema and the resulting XmlSerializer attributes say "This object can be either an object or a GreetingType." Well, a GreetingType IS an object, so the 2.0 serializer happily obliges.

Reversing those two lines in the XSD and regening the CS file with XSD.EXE expresses the correct intent. "This object can be a GreetingType or any other kind of object." and the expected (original) output is achieved. If Dan can't change the original schema (which is likely wrong) then he'll have to change the generated code to get the semantics he wants. Not a bad thing, actually. I did the same thing with the code generated from the OFX schemas.

Using a previously published tip called HOW TO: Debug into a .NET XmlSerializer Generated Assembly I add an app.config with these lines:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <switches>
      <add name="XmlSerialization.Compilation" value="1" />
    </switches>
  </system.diagnostics>
</configuration>

And check the contents of the Temp Directory by going Start|Run and typing in "%temp%" and pressing enter. I then sort by Date Modifed.

I run the test program twice, once the original way and once with the lines reversed (my "fix") and diff the geneated .cs files in BeyondCompare.

You can see from the picture above exactly where the difference is, in the middle of a series of if/elseifs that basically are saying "what kind of object is this?"

The XmlSerializer is glorious and wonderful until it's totally not. I know that's not going to make Dan or his team feel better, but hang in there, it gets better the more you use it.

UPDATE: Dan has an interesting update that points out that the order of the attributes generated isn't regular, nor is the order they come back via reflection. James weighs in as well. My solution worked because there were only two attributes. Nutshell - order matters, but it's not regular.

I'm not defending the XmlSerializer folks, although it may sound like I am. James says "it looks like a bug to me." Personally I think it's less a bug and more a complex and poorly documented edge case that highlights the funamental differences between the XML type system and the CLR type system. At the edges, it's dodgey at best.

I think where we're all getting nailed here is that that XSD Type System can represent things that the CLR Type System can't. Full stop.

In Schema, xs:choice is a complex thing, much like unions in C. The XmlSerializer chooses to present xs:choice as a Object that you have to downcast yourself. The mapping is uncomfortable at best. However, beyond this one uncomfortable type mapping, there are structures you can present in Schema that simply have no parallel in the CLR and the mappings won't ever been 100%. This is just what happens when translating between type systems. The same thing happened(s) for years with nullable DB columns as simple types got translated into the CLR and we leaned on IsDBNull. With the XmlSerializer they introduced the whole and parallel field with a "Specified" suffix.

In this instance, if it were me using this schema and dealing with these documents I'd switch over to implementing IXmlSerializable. IXmlSerializable provides coverage for the final few percent that the XmlSerializer doesn't provide.  It doesn't solve the problem of mapping between type-systems, but it at least puts YOU in control of the decisions being made.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I've been having an interesting back and forth with Sean Lyndersay, a Senior Program Manager on the RSS Team at Microsoft.

I noticed that Office 2007 - specifically Outlook 2007 - registered itself as a system-wide handler (without asking) for the feed: psuedo-protocol. Omar and I added support for feed: in DasBlog and half the users loved it and half hated it. I've always liked the idea, and the user experience of single clicking on a feed icon/link and getting a "would you like to subscribe."

The IE7 release will include the underpinnings for the new system-wide feed API. However, while Outlook 2007 Beta 2 includes support for RSS within PSTs, registers for feeds, and downloads feeds in the same dialog as mail, it doesn't appear to use this system wide RSS API or the Common Feed list.

Office 2007 Beta 2 doesn't appear to install the new RSS Platform at all!

UPDATE: There is an option in Tools|Options|Other|Advanced called "Sync RSS Feeds to the System Feed List" so that may mean that while Outlook stores RSS Feeds itself, it can update its internal OPML with the Common Feed List. Presumably 'System' in this case is the Common Feed Storage. Not sure if this means sync the feed URLs or the content itself.

Hopefully this will change before release, otherwise Outlook 2007 has just added an iffy RSS reader as a feature.

Here's Outlook having registered itself as a handler, after I clicked on my own feed from within Firefox. If I selected "Remember my choice" it'd be a one-click deal.

This is a reprinted part of my back and forth email with Sean and the team, posted with permission. Perhaps the RSS Team will post a little more about the integration between the new RSS Platform, IE7, Vista Beta 2 and Outlook 2007 Beta 2.

---

From: Scott Hanselman
To: Team RSS
Subject: Feed Protocol

Hi,
I was surprised while running Vista 5308 that feed:// wasn't (didn't appear to be) supported in IE7. I was going to blog about it, but I wanted to get the straight story. What's the deal?
Scott

---

From: Sean Lyndersay
To: Scott Hanselman

Scott,

This is an interesting question. The short answer is that we think that the
feed: "protocol" is an unnecessary feature, for a few reasons:

First, IE7 itself does not need a feed: link in order to decide whether a file is a feed, since we look at autodiscovery links in webpages, mime-types, and a few other things (see: section II of http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx) to make this decision.

Secondly, the existence of the feed: "protocol" implies the notion of a default feed reader -- a single client for consuming all feeds.

With the Windows RSS Platform that ships with IE7, and in particular the common feed list, we want to deprecate the notion of a single feed reader, and instead, promote the idea that feeds can and should be consumed from multiple different applications (often simultaneously). We have provided a rich API and event system for enabling applications to be notified whenever a user subscribes to a feed. They can then use that information to add the feed to their own feed lists, or they can use the common feed store to get the content of the feed directly (these different methods of integrating with the RSS platform are documented here:
http://blogs.msdn.com/rssteam/archive/2006/02/09/528195.aspx).

Finally, registering for feed: would then mean that we would be fighting over ownership of the feed: "protocol" with various aggregators on the machine, which is something we really don't want to do. We would rather that publishers and aggregators move away from using feed:// towards simply declaring appropriate mime-types for their feeds (or, if that isn't possible, making sure that their feeds are easily detectable from the first few bytes of the file).

Hope this helps explain why IE7 doesn't register for the feed: protocol. Let me know if you have any questions.

Thanks,
Sean

---

From: Scott Hanselman
To: Sean Lyndersay; Team RSS

Thanks for your reply. Do let me know if I may blog selected portions of this discussion.

I understand your point of view, but there are certainly a number of other non-protocol protocols, particularly in the media space (real, windows media, iTunes) that have associated apps registered as the default. The other obvious one is mailto: even though I use hotmail, gmail, outlook express, outlook and thunderbird. If I follow your logic then a "mail store" would be in order as a platform service and the mailto: pseudo-protocol would be an unnecessary feature.

Feed: is nice because it's explicitly saying "this is a feed." You say that IE7 uses a number of techniques to (my word) "glean" if a feed is a feed. If you (Windows Platform) implemented a "feed" handler ala Open|With that simply enumerated the installed readers and provided the user with the option. Precedent for this already exist with file extension/type and mime/type handlers. Why treat RSS any differently? The idea of an "open with/subscribe" with global (chained) handler not only solves the problem of "fighting aggregators" but it respects and explicitly recognizes that there are a number of aggregators out there. Additionally it respects the fact that there are a number of OSs out there that don't have common feed storage, Windows included, and won't until everyone upgrades to IE7. With the continuing popularity of FireFox, do you anticipate folks upgrading to IE7 *just* for the RSS Platform or will that be a separate redist?

I think that by eschewing feed: you might take a considerable hit in the blogosphere as the folks who came up with feed: did it because the community asked for it. Taking it away or ignoring it I think could cause controversy.

Just my thoughts...

Scott

---

From: Sean Lyndersay
To: Scott Hanselman

Thanks for the thoughtful response. I'll blog about this on our blog later this week, which should give you all you need point to and blog yourself. :)

Taking this out of the philosophical and into the practical, the first point I should make is that we haven't "taken away" the feed: protocol. It still exists, any aggregator can register for it, any publisher can use it, and it will operate just as it did with IE6 (or any other browser). We just choose not to register for it.

With IE7 and Firefox 2.0 (following Safari 2.0 and Opera 8.0), all major browsers will natively support viewing RSS feeds and all will provide entrypoints for aggregators to learn of the user's intent to subscribe to a feed. For browsers that don't render feeds natively, we recommend doing what feedburner does (e.g. view this page in a non-IE7 browser http://feeds.feedburner.com/BurnThisRSS2) -- which is to provide an XSL stylesheet that provides options, including feed:, for users who can't or won't upgrade.

The fact is that feed-protocol was created for a reason, and that reason is going away. It was a less-than-optimal solution even at the time (see, for example, the creator of Feeddemon said: http://nick.typepad.com/blog/2004/06/feeddemon_and_t.html), and it is now longer the right solution.

In my own experience, sites that use feed: protocol appear to be fairly rare in practice. Of course, now that I've said that, I'm sure you'll point me to a few dozen of them :) (Scott: Just Outlook 2007 Beta2)

There are several better ways for a publisher to say "this is a feed" that fit cleanly into the HTTP design. We have recently documented them all on our blog [1].Firefox uses the same rules. We don't need an additional one.

Hope this helps.
Sean

[1] http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx.

---

I think that we both make a number of good points, and I appreciate that Sean acknowledges that the feed: protocol isn't going away, but IE7 isn't going to support it directly and I understand his point.

That said, I suspect that the first utility I will write after installing IE7 will be a system-wide feed: protocol handler that simply adds a feed to the RSS Platform Common Feed Store. That'll satisfy my one-click fix, making use of the clean protocol handler API and the clean RSS API. It's a win-win.

I recognize that when a new Platform API ships - like the RSS Platform API - that not everyone can turn the ship around - like Office 2007 - and get on board with a new dependency. However if the Windows Desktop Search folks got their hooks into the Outlook 12 Team and got them to coerce me into installing yet another Desktop Search Engine when my preferred engine is Google Desktop, the RSS Team should be able to whip them into shape and get them onto the RSS Platform API and get them behind the party line when it comes to the feed: protocol.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By