Note to MSDN: Make friends with the Lazy Web

A couple of months ago I spoke with Jeffrey Snover, who is the architect of MSH (aka Monad), Microsoft's new object-oriented command shell. At the time, I didn't get to see a demo. Yesterday, Chris Sells pointed to the episode of the .NET show that includes a Monad demo by Snover and Jim Truher. Sells also notes that the beta of Monad is available for XP and Server 2003, so I've registered for the download. The concept is wonderful: a Unix-like shell where the stuff that gets piped around is self-describing, either in the form of .NET objects or their XML serializations. Although it targets "the Longhorn wave," I'll be curious to see what Monad can do on current Windows OSs.

I was hoping to use Rich Persaud's AV clipping service to point to some interesting parts of that Monad demo. That service, which inspired the experimental MP3 clipping service I tried on Tuesday, also enabled me to quote from the Apple WWDC keynote on Wednesday. To form URLs that quote from Real, QuickTime, and Windows Media streams, you just need the URL of the stream. Which, in the case of MSDN broadcasts, is either hard or impossible to find.

Here's the home page for the episode of the .NET show that includes the Monad demo. Here's the URL behind the "Watch it now!" button. Here's the XML manifest embedded in that URL. And here, from deep inside that file, is a reference to the actual .WMV file:

<mediaVideo identifier="060EDE76_49D9_423B_8DA3_D6DB5039745E" 
  xlinkHref="netsow43_mbr.wmv" xlinkActuate="onLoad" xlinkRole="ecrs">

So the URL for the movie must be http://msdn.microsoft.com/theshow/episode043/netsow43_mbr.wmv, right? Nope. How about http://msdn.microsoft.com/theshow/netsow43_mbr.wmv? No joy. I did a bit of spelunking in the layers of IE-and-Windows-Media-player-specific JavaScript wrapped around that filename, but came up empty-handed. My guess is that the pathname is buried in some piece of server-side code.

Now, MSDN does an awesome job with its webcasts. If you access them from IE -- which, unfortunately, is the only way you can access them -- you'll find that the transcripts are linked to the video with exquisite care, like so:

<div id="p01:12:23"><img src="/seminar/shared/images/playsync_stat.gif" 
 alt="Jump to #85" hspace="2" border="0" align="absmiddle" class="PrintNever"
 onclick="callSeek('01:12:23');" onmousedown="downPlaySync(this)" 
 onmouseout="resetPlaySync(this)" onmouseover="this.style.cursor='hand'; 
 togglePlaySync(this);" />
<b>JEFFREY SNOVER:</b>  Yeah.  So now let's focus in on even a more 
sophisticated example where again you have the MSH do more work for you.  
This is the code to stop a process.  Again it's a class, again you put 
the commandlet attribute on top of it and here we have a public int, 
array of integers, called ID.  So we're going to kill processes by 
their process ID and we've got attributes on top of it.  
<div class="code"><pre>
[Cmdlet("stop", "ps1")]
public class StopPs1: Cmdlet
{
	[Parameter( 
		Mandatory = true, 
		PipelineInput = PipelineInput.ByMatchingProperty, 
		Position = 0)]
	[Prompt("Where's the ID dude?")]
	public int [] Id;
	public override void ProcessRecord()
	{
...
</pre></div>

This is incredibly well done. And yet, the entire presentation is hermetically sealed. From the outside, there's only a single IE-accessible entry point. Conspiracy theorists will doubtless find evil here. I don't. If MSDN wanted to assert total control over this content, it wouldn't offer downloads:

Offline Viewing Download: For those of you who want to download a copy of this episode to your local hard drive for off-line viewing, we provide this as a separate file (self-extracting .exe) that you can download. We now offer two file size choices, depending on the bandwidth of your Internet connection and a third one especially for mobile devices.

300 KB version (246 MB file)
100 KB version (87 MB file)
Mobile devices version (78 MB file)

What is evident, though, is a cultural reluctance to work with the Web on its own terms. MSDN's predilection for publishing URLS that point to self-extracting .EXEs, rather than (in this case) to .WMV files, is really quite odd. My advice: point to the .WMVs too. You've already invested a huge amount of effort in this stuff. The content is intended to be public, and its purpose is to evangelize. So, why not trust the Web and let it help you do that? If you make the URLs directly available, here are some of the positive effects that can ensue:

A blogger could point directly to one of your timecoded fragments, or use an AV clipping service to point to a newly-constructed fragment.
A Firefox user on Mac OS X could access the content. You don't want to just preach to the converted, do you?
A transcoding service could (in theory) make the video accessible in non-Windows-Media formats.

If you let it, the LazyWeb will be your friend. You needn't implement any of these ideas, you just need to publish the URLs that enable others to do so.

Update: Ace detective Alf Eaton took up the challenge, and has extracted the URL I was looking for. The trick is to hit the "Watch this video" URL with a user agent that pretends to be IE but isn't. Alf did that using the debug feature of Safari. Armed with this insight, I was able to do the same thing with the command-line tool curl:

curl -A "Mozilla/4.0 (compatible; MSIE 5.5)" \
  http://msdn.microsoft.com/seminar/shared/asp/view.asp?\
  url=/theshow/en/episode043/manifest.xml

which, as Alf discovered, yields:

/theshow/en/episode043/netsow43_mbr.asx

which in turn yields:

mms://wm.microsoft.com/ms/seminar/en/Episode043/netsow43_mbr.wmv

Thanks Alf! Now, where was I? Oh, yeah, I wanted to highlight a couple of things:

Cool stuff.

Former URL: http://weblog.infoworld.com/udell/2004/07/02.html#a1032