Windows Live Quantum Mechanics : Windows Live

MIX07 UK Podcast with Craig Murphy

dthorpe — Mon, 24 Sep 2007 20:37:18 GMT

I sat down with Craig Murphy to chat about Windows Live and life in general at MIX07 UK. Craig has just posted a podcast of that conversation.

I've known Craig for many years through the Delphi community. I think we first met in person in 2001 at "The Delphi Conference" run by the Borland User Group UK. Aha! Found a photo. Craig got his start as one of the pillars of the Delphi developer community - particularly at the Scottish end of the isles. Today he provides much the same community organizing and informing service over a much broader swath of tech topics as a Microsoft MVP.

MIX07 UK Blogging

dthorpe — Sat, 15 Sep 2007 06:54:51 GMT

The title of honorary MIX07 UK stenographer goes to Sebastien Lambla (aka SerialSeb)for transcribing nearly word for word just about every session he attended this week, in realtime! Check out the detail in his notes on "Building Next Generation Web Applications using Windows Live Services", for example. He has half a dozen more posts on Mix07 UK just as detailed. Way to go SerialSeb!

PodCast Interview on LiveSide.Net

dthorpe — Sat, 15 Sep 2007 06:20:42 GMT

Angus and I had a chat with the guys from LiveSide.Net during the MIX07 UK conference this week. Check it out!

Halo 3 Promo Videos Running on Silverlight Streaming

dthorpe — Tue, 04 Sep 2007 21:32:44 GMT

The promotional campaign for the new Halo 3 FPS has begun with a series of in-game and thematic live action videos. High-def 2mbps videos are here: http://halo3.msn.com/videosHD.aspx Lower bandwidth versions of the same are here: http://halo3.msn.com/videos.aspx These are already on the msn boards and will be referenced by additional promotional spots throughout the rollout.

How is the Halo promotions team serving up video to tens of millions of viewers over the next few days and weeks? With Silverlight Streaming! The video player is built with Silverlight, and the video content is being served up by Silverlight Streaming. (The last of the HD vids are being moved to SLS this afternoon to better handle the traffic volume)

Way to go team!

MSN's The Podium 08 - Built On Silverlight

dthorpe — Sat, 25 Aug 2007 02:54:52 GMT

MSN just launched The Podium '08 as part of their 2008 US Presidential election coverage. The Podium '08 brings together data on presidential candidates for voters and election followers to explore by topic and compare candidates head to head on specific issues.

What's interesting about The Podium is that the content is not canned editorial material. When you select a candidate and click on a specific issue (say, Immigration) to see where the candidate stands on that issue, the list of articles displayed is actually drawn from Live Search on the fly. As new articles appear on the web on these candidates and these topics, those articles will appear in The Podium 08 for that candidate and topic.

The Podium 08 is built using Silverlight 1.0 to present a slick, modern rich UI experience that seamlessly and intelligently integrates services on the back-end.

Want to see what Software plus Services means to the average Joe? Take a look at The Podium 08.

Windows Live SkyDrive

dthorpe — Wed, 15 Aug 2007 21:58:10 GMT

Windows Live SkyDrive (formerly known as Folders) is now in beta, enabling end users to store arbitrary data on the web under password access control. Files can be accessed over http(s) from web pages and from stand-alone client applications (thanks to the http file handler add-on in XPSP2). Files can be private to your Windows LiveID only, shared with other specific users (via their Windows LiveID), or publicly accessible to everyone on the Internet, anonymously.

The layout feels similar to SharePoint, with web-based directory trees and file metadata browsing and editing. There's no mention of drive letter mapping (ala file shares) in the SkyDrive intro docs, but I'm sure someone will create a utility to map your private SkyDrive folder to a local drive letter. It'd certainly be a slick way to shortcut the traditional file upload process.

SkyDrive isn't a web host - it's not intended to be the place from which you run a web app (html content), but you can store files in SkyDrive that are referenced by your web app running on your own server or hosted provider. Browser cross-domain barriers stilly apply: you can easily reference JavaScript or image files stored on your SkyDrive from your web site, but the JavaScript in your web pages will not be able to read or write the SkyDrive files directly because they reside in a different domain than your web app.

You can link to individual files in your SkyDrive storage using plain old URLs, like this: Paradoxes in Web App Development or you can embed a "badge" for the file in your web page in a couple of different styles, like this:

or this:

You can also embed a folder to direct viewers to whole directories of related file content:

This will make it a lot easier to post presentation slide decks, podcasts, code samples and demo app source code for blog articles!

New In The Windows Live Contacts Control: Incremental Search!

dthorpe — Thu, 09 Aug 2007 01:01:03 GMT

Another month, another release! This month we've added incremental search to the contacts and presence controls to make it easier to find a particular contact in your haystack of hundreds of family, friends, and coworkers. Just type in a few letters of the name or word you're looking for, and the control will reduce the list of displayed contacts to only those that contain that letter sequence, anywhere in the contact display name, case insensitive.

Check it out in our little control testbed apps: http://dev.live.com/mashups/trycontactscontrol and http://dev.live.com/mashups/trypresencecontrol

While we were at it, we also added support for filtering the list by group as well. Click on the dropdown button to the right of the search box to select from a list of groups you have defined in your addressbook. In the Contacts Control in tile view, you can also filter by online state, to display only your buddies that are online, for example.

We've cleaned up the control UI a bit, too. The info panel below the contacts list didn't get favorable reviews from the field, so we've removed it to make room for displaying more contacts in our always-cramped-for-display-real-estate web control. The edit and delete buttons that bordered the info panel have been moved to the display contact details page. You really ought to review the details before editing or deleting anyway, so putting them all on the same page makes sense.

What do you need to do to pick up these new features? Nothing! It's an inline release on the v0.3 version. As long as you're referencing http://controls.services.live.com/scripts/base/v0.3/live.js and http://controls.services.live.com/scripts/base/v0.3/controls.js in your web page, you'll get these enhancements and refinements for free.

Enjoy!

Custom Colors in the Windows Live Web Controls

dthorpe — Fri, 29 Jun 2007 01:26:42 GMT

The Windows Live Web Controls now support custom colors! The Windows Live Contacts web control and Windows Live Spaces web control now accept additional parameters to specify the text and background colors of the inner and outer regions of the controls so that you can "skin" the controls to more naturally blend in with your web site's color scheme.

So you can now do this:

We use the term "inner" and "outer" because the inner region serves slightly different purposes in the different controls. In the Contacts Control's list view, the inner region is the listbox containing the scrollable list of contacts. In tile view, it's a list of contact photo tiles. In the Spaces Control, it's a list of photo thumbnails.

The Windows Live logo banner is now a transparent PNG with an alpha blended halo to provide contrast against any background color.

The color parameters are:

OuterBackgroundColor
OuterTextColor
InnerBackgroundColor
InnerTextColor
LinkColor

These color parameters determine the screen color for everything in the controls displayed in-situ on your host page except for the submit button, the scrollbar, the piping and the Windows Live logo. Popup windows for Windows Live login or user confirmations, error messages, and user prompts are not affected by custom colors.

The color values you can assign to these color parameters follow the W3C CSS color specification: 15 color names, plus hexadecimal notation (#FFFFFF), plus RGB octets notation ("rgb(255,255,255)").

The "try*" demo apps have also been updated to help you configure the colors interactively and see how they look: trycontactscontrol, trypresencecontrol, trystoragecontrol

Enjoy!

Secure Cross-Domain Communication: The Architecture Journal

dthorpe — Tue, 19 Jun 2007 01:53:50 GMT

The June issue (Journal 12) of The Architecture Journal focuses on web architecture. I was delighted to be invited to contribute, and wrote "Secure Cross-Domain Communication in the Browser" for this issue. In the article I describe a somewhat bizarre technique we use in the Windows Live Contacts web control and Windows Live Spaces web control to move data from HTML pages running on *.live.com to and from third party web sites. This is how the contacts control returns user-selected contact data to the page hosting the control, a web site that is not a Microsoft site.

The print edition of Journal 12 is out already and was handed out at TechEd in Orlando earlier this month. You can request a print copy by registering on the Journal's web site, or you can just grab the PDF and read it on-screen. Journal 12 will rotate into the headlines on the Journal's homepage soon.

A few posts ago I mentioned I could finally reveal what I had been working on at Google. Now I can also tell you in exquisite detail what I've been working on here at Microsoft for the past year and foreseeable future: cross-domain browser communication techniques. Coaxing stubborn little bits to migrate through impenetrable browser barriers.

"Secure Cross-Domain Communication in the Browser" is a high-level walk-through of the iframe URL technique of passing information between domain contexts in the browser, it's limitations and weaknesses, and the approach we've taken to build a channel communications library to fortify against those weaknesses and limitations.

Over the next few weeks I will be posting here on Windows Live Quantum Mechanics a series of articles digging into the nitty gritty of cross-domain communication, why it has been taboo in the browser, why it's time to change that perception, and techniques and code you can use today to achieve it - without compromising security or server scalability.

Cross domain communication would be much easier with the browser's help and shepherding, but with a little bit of effort we can actually do quite a bit today - safely - in spite of the browser's objections.

Windows Live Web Controls Mix07 Video

dthorpe — Mon, 18 Jun 2007 21:40:23 GMT

In the better late than never department, a video interview with Koji and me from the week prior to MIX07 is now posted on Channel 9: http://channel9.msdn.com/ShowPost.aspx?PostID=317385

Yay! Thanks Catherine for pushing it on through.

New Domains for Windows Live Web Controls

dthorpe — Fri, 15 Jun 2007 00:42:00 GMT

Our little web controls are growing up so fast! We've migrated the Windows Live Contacts web control and Windows Live Spaces web control to new servers in the Microsoft datacenters and a new domain name: controls.services.live.com.

The web controls will continue to work on the old domain name (dev.live.com) during the beta period for existing apps, but you should consider updating your web apps to use the new URL as soon as possible. Why? Better performance! The new configuration serves up the controls faster than ever.

Moving to new physical servers in the Microsoft data centers could have been done without a code-breaking domain name change (the old servers were not in MS data centers, fwiw), but we decided now was the best time to bite the bullet and make the domain name change. The new controls.services.live.com domain name aligns with the Windows Live Services platform map rolled out at MIX07 this past April, and allows us to make a clean separation between information content and live web services. dev.live.com will continue to be the developer information portal on how to use Windows Live services in your applications. The actual services your code talks to will be under *.services.live.com. This will also help prevent sudden surges in web traffic on the content site from affecting the performance of the web services themselves.

Make the Switch

To switch your web apps to use the new servers, you need to change script tags referencing dev.live.com to controls.services.live.com, and change v0.2 to v0.3 in the URL path:

<script type="text/javascript" 
src="http://dev.live.com/scripts/base/v0.2/live.js">

becomes

<script type="text/javascript" 
src="http://controls.services.live.com/scripts/base/v0.3/live.js">

In addition, if your code still references http://dev.live.com/scripts/contacts/v0.2/control.js, change that to http://controls.services.live.com/scripts/base/v0.3/controls.js. Note that the old file was singular "control", whereas the new version is plural "controls". The old file (singular) only knew how to bootstrap the Contacts control. The new file (plural) has been refactored so that it can recognize and bootstrap multiple different Windows Live web controls on a page. One script reference to rule them all and in the darkness bind them. Or something like that.

While you're cleaning out cobwebs, it'd be a good idea to copy the latest channel.htm to your server. We've made a few minor adjustments to it for bug fixes, stability and performance that you should get.

Bonus!

Also new with this v0.3 release: New languages for the Windows Live Spaces web control! The Spaces control now supports the same 10 languages as the Contacts control: Dutch, English, French, German, Italian, Japanese, Korean, Spanish, and Chinese Simplified

Enjoy!

A Cross-Domain Silverlight Channel 9 VideoRSS Player

dthorpe — Wed, 30 May 2007 11:26:00 GMT

Last week Kevin Ledley, keeper of the dev.live.com content, asked me for a bit of help to get a Silverlight video player working. He wanted to "borrow" the cool scrolling video list and video player from our sister site, msdn2.microsoft.com and set it up on our dev.live.com homepage to show Windows Live related videos from Channel 9. Copying the necessary JavaScript and XAML files for the Silverlight video player was easy enough, but even after fixing all the URL references, it still wasn't working. So, I took a look.

Get the files

First, I needed to grab the files and set them up on my localhost IIS server. The msdn2.microsoft.com page referenced the following JS files:

Silverlight.js - we know what that is
main.js
button.js
helpermethods.js
listbox.js
listboxitem.js
scrollbar.js
transportButtons.js
videoEntry.js
videoPlayer.js
videoService.js

main.js is what makes the call to create the Silverlight control, same as our CreateSilverlight.js file in helloworld earlier. main.js has a lot of other code in it as well. Scanning for ".xaml", we find there are actually three different xaml files used by main.js:

videoListHor.xaml
itemTemplate.xaml
videoPlayer.xaml

After copying these files locally, I scanned each for hard coded URL references and stripped them down to relative paths for easier tinkering on localhost.

I made a small test page to host the video player, using the same variable and element names as the original msdn page:

vidtest.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        <title>Channel 9 Video on Silverlight</title>
        <script src="SilverLight.js" type="text/javascript"> </script>
        <script src="main.js" type="text/javascript"> </script>
        <script src="transportButtons.js" type="text/javascript"> </script>
        <script src="listbox.js" type="text/javascript"> </script>
        <script src="listboxitem.js" type="text/javascript"> </script>
        <script src="button.js" type="text/javascript"> </script>
        <script src="scrollbar.js" type="text/javascript"> </script>
        <script src="helperMethods.js" type="text/javascript"> </script>
        <script src="videoPlayer.js" type="text/javascript"> </script>
        <script src="videoEntry.js" type="text/javascript"> </script>
        <script src="videoService.js" type="text/javascript"> </script>
    </head>
    <body>
        <div style="position: relative;text-align:center;width:475px; z-index:10;">
            <div id="videoListHost">
                <script type="text/javascript">
                    var videoScrollerFeedUrl = 
"http://www.mscommunities.com/MixItUp/Search/default.aspx?q=msdn";
                    startVideoScroller();
                 </script>
            </div>
            <div id="videoPlayerHost" >
            </div>
        </div>
    </body>
</html>

With this in place, I had all the bits in place on the localhost server to run the app. Would it work? Probably not, but no harm in trying!

Eliminate Framework Dependencies

Sure enough, vidtest.html threw a JavaScript exception on load. The culprit: Some of the code in the js files refers to a $get() function which appear to be a shortcut for document.getElementById. A little bit of spelunking around in the msdn code with a JavaScript debugger confirmed this hypothesis. $get() is a helper function implemented in the JavaScript libraries that run the msdn web site. I definitely did not want to start pulling on that thread. $get() is innocuous enough, so we can placate the borrowed JS files on our localhost system by implementing a $get() function in vidtest.html

function $get(id) {
    return document.getElementById(id);
}

Easy enough. Will it work now?

Bzzzt! The browser next complains about "Object required" or somesuch on the expression Sys.Application.notifyScriptLoaded() at the bottom of one of the .JS files. This, too, is a bit of goo defined by the msdn web site infrastructure. It notifies the application when the .JS file has finished loading, so that it's ok to construct the Silverlight control.

For vidtest.html, I have an equivalent, simpler approach: construct the Silverlight control in the onLoad event of the body element. The page's onLoad event won't fire until after all the JavaScript references in the head of the document have been loaded.

Ok. Will it work now?

Yes! The Silverlight video scroller draws itself on the page!

But it's empty. Why is it empty? Let's go look at that videoScrollerFeedURL variable and where it's used in the code.

A quick grep of the JS files brings us to videoService.js, in a function called getVideoEntryList:

function getVideoEntryList() {
    Microsoft.Mtps.Rendering.Behaviors.VideoService.GetVideoEntryList(
        videoScrollerFeedUrl, loadVideos);}

What's all that about?

Bubble Burster

videoScrollerFeedUrl is a string with a value of http://www.mscommunities.com/MixItUp/Search/default.aspx?q=msdn. If you follow that link, you'll see that it's an RSS feed. But you should also notice that the URL is in a domain that is not msdn. How is the msdn web code able to use the RSS data from mscommunities.com?

Microsoft.Mtps.Rendering.Behaviors.VideoService.GetVideoEntryList must be a cross-domain proxy of some kind responsible for fetching RSS entries from mscommunities.com and returning them to the JavaScript running on msdn.microsoft.com. A little friendly debugger inspecting confirms that this function call receives back an array of JavaScript objects - a JSON result - describing the video description, a thumbnail image URL and a video stream URL.

This presents a not so small problem for our objective. dev.live.com is not msdn.microsoft.com. We can't call that GetVideoEntryList function or use the web service behind it to find out what videos are available on Channel 9. Full stop.

The Options: Few and Ugly

I called Kevin up with the bad news. Our options were few and ugly:

Get the server proxy code from msdn and install it on dev.live.com. Great plan, but even if we could get our hands on the code, chances are high that some sort of server configuration difference (installed version of ASP.NET, installed version of .NET framework, etc) between how msdn is set up from how dev.live.com is set up could still make this a no-go.
Write our own server side proxy to perform the same relay of RSS content. Trivially simple, perhaps, but the depth of security and code reviews and testing that would be required to roll out live code on a production server would turn our cute little video thingie into a weeks-long fire-breathing hydra from hell. No thanks. I already do that for my day job - why take on all that for a side project?
Hardcode the URLs of the videos we want shown in this video scroller into the JS code. Kevin: "We don't have that many videos." Danny: "Yet." Doesn't scale, labor intensive.
Construct an RSS feed on the dev.live.com domain to feed video URLs into the video scroller. Much more maintainable over time than #3, but still requires constant maintenance to update the local feed when something relevant shows up on Channel 9. The whole reason for RSS is to have the machine take care of discovery and updating.

Kevin said he'd work on #1 and #4. I opted for #5: Stew on it some more. Take the dog on a long walk. Check the mailbox. Return.

Strange Bedfellows

A funny thing happened on the way back from the mailbox - it dawned on me that I was trying to solve the wrong problem, or at least, more problem than we needed to solve. We needed a way to read the video RSS feed in the browser across domain boundaries, but we didn't need an all-purpose cross domain data conduit (like we use in the Windows Live Contacts web control). A conduit that could move just RSS data and only RSS data would suffice for this project.

That's when I recalled hearing about Google's recent launch of an RSS Feed API. Mark Lucovsky, who I had a chance to meet (and almost work for) in my Google days now 400 days ago, announced about a month and a half ago a new API built from a subset of the Google Search API that returns only RSS data.

In concept, the Google Feed API acts as a cross-domain proxy service between your web app and the RSS content you want to use. In reality, it's far simpler: it returns the RSS data cached in Google's search index. This approach creates a multitude of curious artifacts with positive and negative spin:

Response latency to your RSS requests is determined solely by Google's network infrastructure, not the server originating the RSS data. The server of origin might not even be up but you can still get the RSS data from the Feed API.
This use of RSS data is entirely in the spirit of syndication. It's a bummer that the server of origin can't find out how many secondary and tertiary consumers of their data are out there, but hey, that's the nature of syndication.
The RSS data you get from the Feed API could be stale or out of sync with the server of origin by several hours or more depending on how quickly Google's web crawlers return to the server of origin to index new content. That's not a major concern for our video viewer, but could be a show stopper for, say, live broadcasting.
It's possible the RSS feed you want is not indexed by Google. Hey, it does happen - the RSS feed could be too new to be in the index, or too isolated (no inbound links) to be considered indexible, or the server of origin could have a robots.txt file that tells search engine spiders to piss off. It seems a bit contradictory to have an RSS feed that does not want to be found, but stranger things have happened.

Wait a second. Use a Google API in a Microsoft app? What blasphemy is this?!

Oh, grow up. Use what works. Windows Live Search has a perfectly good Search API, but it doesn't provide anything to bring RSS content from a specific RSS URL into our web app.

And why shouldn't a Microsoft app use a Google service when appropriate? Google certainly uses plenty of Microsoft browsers and operating systems to reach end users!

API Keys

To use the Google Feed API (I don't know why they had to put "AJAX" in the middle of it), you have to agree to the usual mile long list of terms of use plus generate an API key associated your web site URL. You use the API key when initializing the Google API subsystem. Presumably, this is so they can get an idea of how much traffic your app is generating and be able to block your app's access if you're found to be abusing the system or violating the ToU.

As far as I can tell by experimentation, the API key only gives Google some idea of who is using their service; the key does not appear to automatically disable API access if the key is used from a domain different from the URL you specified when you generated the key. I generated a key for use on localhost, but found that it works just as well when I run my app from 127.0.0.1. (It doesn't matter that one resolves into the other - a DNS name and an IP address are considered distinct domain names by the browser. Domain name matching in the browser is by string matching, not by what the strings mean) Perhaps lockouts only occur after a significant volume of suspicious traffic goes by. I dunno.

The Brass Tacks

Here's the vidtest main page again, with the Google Feed API spliced in and bootstrapped:

vidtest.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        <title>Channel 9 Video on Silverlight</title>
        <script src="SilverLight.js" type="text/javascript"> </script>
        <script src="main.js" type="text/javascript"> </script>
        <script src="transportButtons.js" type="text/javascript"> </script>
        <script src="listbox.js" type="text/javascript"> </script>
        <script src="listboxitem.js" type="text/javascript"> </script>
        <script src="button.js" type="text/javascript"> </script>
        <script src="scrollbar.js" type="text/javascript"> </script>
        <script src="helperMethods.js" type="text/javascript"> </script>
        <script src="videoPlayer.js" type="text/javascript"> </script>
        <script src="videoEntry.js" type="text/javascript"> </script>
        <script src="videoService.js" type="text/javascript"> </script>

        <script src=http://www.google.com/jsapi?key=xxxGetYerOwnAPIKeyxxx"
          type="text/javascript"></script>
        <script type="text/javascript">
            google.load("feeds", "1");
 

            var videoScrollerFeedUrl = 
"http://www.mscommunities.com/MixItUp/Search/default.aspx?q=msdn";
 
          function initialize() { 
              startVideoScroller();
          } 

 
          google.setOnLoadCallback(initialize);     
 
          function $get(id) {
              return document.getElementById(id);
          } 
    </script>
  </head>
  <body>
      <div style="position: relative;text-align:center;width:475px; z-index:10;">
          <div id="videoListHost">
          </div>
          <div id="videoPlayerHost" >
          </div>
      </div>
  </body>
</html>

We've added a new script reference that pulls in jsapi from www.google.com, and includes our API key. I replaced my API key with a dummy value. You'll need to go generate your own key if you want to run this code yourself.

google.load("feeds", "1") tells Google that we want to use the Feeds API.

google.setOnLoadCallback(initialize) tells Google to call our initialize() function when the requested API has been loaded. Dynamic loading of JavaScript might not be finished before the body onLoad event fires, so we have to take this route to wait for the Feed API to load. Body onLoad event deleted.

Now, let's go load that RSS content and build our video list, in videoService.js:

videoService.js

function getVideoEntryList() {
    var feed = new google.feeds.Feed(videoScrollerFeedUrl); 
    feed.setNumEntries(100);     
    feed.setResultFormat(google.feeds.Feed.MIXED_FORMAT);
    feed.load(function(result) {      
        if (!result.error) {       
            var videoEntries = [];  
            for (var i = 0; i < result.feed.entries.length; i++) {            
                var entry = result.feed.entries[i];    
                var vidEntry = new Object;
                vidEntry.VideoTitle = entry.title;
 
                var test = google.feeds.getElementsByTagNameNS(
                        entry.xmlNode, 
                        "http://search.yahoo.com/mrss", 
                        "content");
                if (!test || !test.length) continue;
                vidEntry.VideoUrl = test[0].getAttribute("url");       
 
                test = google.feeds.getElementsByTagNameNS(
                        entry.xmlNode, 
                        "http://search.yahoo.com/mrss", 
                        "thumbnail");
                if (!test || !test.length) continue;
                vidEntry.VideoThumbnailUrl = test[0].getAttribute("url");
 
                test = google.feeds.getElementsByTagNameNS(
                        entry.xmlNode, 
                        "http://purl.org/dc/elements/1.1/", 
                        "creator")
                if (test && test.length) {
                    vidEntry.Author = test[0].text;
                }
 
                videoEntries.push(vidEntry);
            } 
            loadVideos(videoEntries);     
        }      
    });    
}

The msdn2.microsoft.com video scroller expects an array of vidEntry objects as input to build its playlist. The msdn server side proxy takes care of digesting the RSS XML content down to a simple list of vidEntry objects.

For our dev.live.com version of the video scroller, we need to build the vidEntry objects ourselves. The Google Feed API can return JSON, XML, or both. The title of the RSS entry is standard fare, so that's easy to grab from the JSON field entry.title. The other fields we need - thumbnail URL, video URL, and author - are not normal RSS fields. These fields are defined in the Media RSS (MRSS) RSS extension module and are generated by the Channel 9 video RSS feed as such.

We make short work of finding the exact XML elements we're looking for by using a utility function provided by the google.feeds library: a cross-browser implementation of getElementsByTagNameNS().

We push each vidEntry object into the array and loop until we run out of RSS items.

Finally, we hand off the array of objects to loadVideos and return to the original code path of the video scroller implementation.

The result looks something like this:

Why stop there?

So now we have what we set out to build: a Silverlight video player that can show videos from the Channel 9 libraries, using the video RSS feeds returned by the mscommunities.com query service. Note that this is built on the Silverlight 1.0 beta control using browser JavaScript, not the Silverlight 1.1 Alpha.

The fact that we ended up using a generic RSS provider to get the specific RSS feed we needed opens some interesting possibilities: Aren't we just a hair's breadth from showing any video from any video RSS feed on the Internet? All we'd need to change is the videoScrollerFeedURL to point to a different RSS feed, right? Perhaps this could be wired directly into Yahoo's Video Search service, which returns MRSS results for keyword searches of videos across the web?

The answer is: yes and no. Yes, the app actually is just a small step away from using any video RSS feed, or even a video search service that returns MRSS results. The catch is: there are a bezillion different video formats and codecs out there in the wild. It would be unreasonable to expect Silverlight 1.0 beta to be able to play all of them. Silverlight's media player isn't designed to play all video formats - it's designed to play media content encoded for Silverlight playback, using tools such as Expression Media. Apparently, the Channel 9 video library is already encoded in a format that Silverlight can use. Most video in the wild is not.

That's no ding against Silverlight - all video sharing sites with built-in players play only one video format - their own. When you upload a video to the sharing site, it is almost always converted (transcoded) into the site's native encoding format so that the site's player can play it. You can build that kind of video sharing site with Silverlight.

With a few tricks from this article, you can show Channel 9 videos on your web site or blog pages with Silverlight!

HTML Namespace Attributes and IE document.namespaces

dthorpe — Sun, 27 May 2007 21:27:26 GMT

A few posts ago I promised to elaborate on a little gotcha that bit us in the butt while prepping the "blocks" to enable Popfly apps to use the Windows Live Contacts web control and Windows Live Spaces web control .

Here it is: IE has a handy document.namespaces object that reflects the namespaces defined in attributes of the HTML element of the page.

The gotcha: document.namespaces does not track with attributes that are dynamically added to the HTML element after page load.

The situation: "blocks" in Popfly can emit HTML code to set up shop in the application host page, but they do not have control over the host page's HTML tag. Since our web controls pretty much requires namespaces (that's a bug - they should work with or without namespaces), we tossed in a quick fix in the Popfly block: look up the html element and use setAttribute to set the namespace attributes we would have set on the html tag if we had access to it.

Result: worked great in Firefox, but that was only because Firefox doesn't provide any support for namespaces in HTML docs. I ranted on this awhile back. You have to serve up content type text/xml in order to get Firefox's namespace support to kick in, but doing that kills all the JavaScript on your page, among other things, and in general one should not take lightly renaming HTML as XML or visa-versa. It'll sneak up and bite you when you least have time to deal with it.

Result2: Didn't work in IE. Our bootstrap code in the contacts control takes advantage of document.namespaces in IE, and falls back to savage spelunking to find the namespace attributes the hard way in Firefox and other browsers. document.namespaces is populated when the html document is being loaded and is not updated after it has loaded. Our quick fix of adding the namespace attributes to the html element in our Popfly code block had no effect because they were added after document.namespaces was locked down.

Solution: Change the Popfly code block to call document.namespaces.add() if document.namespaces exists, otherwise add the namespace attributes to the html element. Do it. Test it. Ship it. Whew!

More: Avoiding Popup Windows in Your Web Apps

dthorpe — Wed, 23 May 2007 04:10:34 GMT

Scott Isaacs shares some additional "best practices" points on dealing with popup windows and popup blockers:

Always program window.open() very defensively...

Always try catch any calls to window.open() and if you are retaining a reference to the window (e.g., var w = window.open(…)), always make sure the “w” is a valid object (and again try catch your first attempt to leverage the window).

Last, it was recently discovered that Symantec’s internet products have a popup blocker that actually augments the web page with their own custom script. This script disables any calls to window.open() that may occur before the onload event of the page. Therefore, if the user quickly clicks a hyperlink that calls window.open before the page loads, the user will see either nothing happen or receive a script error.

I heartily agree. The variable assigned the return value of window.open() ("w" above) is particularly obnoxious. It can fail to be initialized if the window.open() failed or took an unexpected detour due to popup blockers. Once the popup window is up and running, the "w" variable will again be at risk when the user closes the popup window. The "w" variable will be unusable after the window it refers to is closed - it's almost as though the object it refers to has been garbage collected out from under the variable. Any reference to the variable will raise an exception. Testing for typeof w == "undefined" isn't entirely reliable across browsers because for the brief period while the window is closing "w" may be unusable but not undefined.

For the Windows Live Contacts web control we ultimately solved these quasi state problems with the popup window variable once and for all by eliminating the variable! Instead of having the main page hold onto a variable pointing to the popup window so that the main window code could check the state of what's going on in the popup, we turned everything inside out so that the popup calls or writes back to the main window. This arrangement allows the main window to create the popup, set a state variable to indicate that the popup is up, and then forget about it. When the popup is closed, it will call back to the main page to clear the state variable and set the result of the operation.

Another thing to watch out for when you have multiple windows in your web app: Firefox 1.x does not do well with executing script while a window is closing. If the popup window is in the process of closing and calls into a JavaScript method on the main page which fires off a new XMLHttpRequest, chances are high that the XMLHttpRequest will implode in its onReadyStateChanged event. Accessing any field or method of the XMLHttpRequest object will throw an exception, and all subsequent XMLHttpRequests (even new instances) will be fried. The only way to clear this state appears to be to reload the main page. I don't recall offhand if this has been fixed already in Firefox 2.0, but it's a known, logged issue in Firefox 1.x

The best solution is to avoid the problem by not initiating an XMLHttpRequest in a call chain started by a window close event. Use a short timer to decouple the closing popup window's call context from the desired XMLHttpRequest action.

Avoiding Popup Blockers in Your Web Apps

dthorpe — Wed, 16 May 2007 00:51:39 GMT

Tim Heuer laments the growing number of otherwise reputable web sites that instruct their flocks to disable popup blockers in order to complete some task within that web site.

Having stumbled into popup blocker hell myself only a few months ago with the Windows Live Contacts Control I can certainly attest to how easy it is for the blissfully ignorant (me!) to get snared by a popup blocker. However, I agree with Tim that popup blockers provide a valuable service and disabling them should not be part of anyone's standard operating procedure, especially when the target audience is the non-technical consumer.

When a web site asks you to lower your shields in order to complete an online order or do some other mundane task, it seems a little odd. But when you consider how easy it is to avoid tripping popup blocker alarms, asking the consumer to disable them is just plain sad.

The purpose of a popup blocker is to block popup "spam" - windows that pop up without the user's consent or request. Some of the more irritating sites throw up dozens of popup windows all at once, leaving the viewer lost in a forest of trash. Some toss up a popup window when you leave their site.

Why do the popup spammers do it? To artificially inflate their page view counts. A browser popup window showing a particular HTML page counts as a page view, whether the consumer is looking at it or not. Most banner advertisers consider that action a form of click fraud, and at a minimum grounds for termination of your ad serving account.

Here's the deal: Popup blockers in web browsers don't block all popup windows. A popup window that is opened in direct response to a user action, such as a button click, will not trigger a popup blocker alarm. If you do a window.open() in a JavaScript button click event, the window opens without issue. If the same code executes in a timer event, it will trip a popup blocker alarm. Why? Because a timer event is not the direct result of a user action.

The same goes for page loads, page unloads, XMLHttpRequest events, or anything else that is not a direct user action implying consent. Mouse clicks are user actions. I haven't tried this, but I'd be willing to bet that mouse hovers over an HTML element do not qualify as a user action. If anything, waiving the mouse around on the screen indicates indecision!

Different popup blockers have different degrees of sophistication in how they determine whether a window.open() is happening in response to a user action. Some may tolerate a call to window.open() being made in a subroutine called by a click event, but for best results across the board keep the window.open as close to the click event as possible. Meaning: keep the window.open in the click event itself.

We tripped over this in the first iteration of the Windows Live Contacts Control's WriteAPI. When a third party web app submits contact data to the Contacts control, we need to make sure the user is aware of what the third party app is doing, so we need to show the submitted data to them and ask for their approval of the action. There isn't enough screen real estate in the control itself to display the potentially large data, so a popup window is justified.

Let's say the user clicks a button on the third party web page to send data into the contacts control. The web app calls a method on the Contacts control, which is actually JavaScript from our library executing in the context of the third party app. Our code sanity checks the data, then bundles it up and tosses it over the domain barrier to our code that lives inside the Contacts control iframe, hosted on a Microsoft domain. Our code on the inside checks the data again, then opens a popup window to ask the user to review and approve the submitted data.

That's where we got caught - the JavaScript code opening the popup window was not directly tied to a user click. In our minds it was the direct result of the user click, but in the reality of the browser there were far too many call frames and other indirections between the user action and the window.open for the popup blocker to determine a causal relationship between them.

One solution that came to mind (very briefly) was to display the confirmation popup window from our code that executes in the context of the third party web app. This has many problems, not the least of which is that we cannot trust code that is executing in the third party domain context. We can only trust code that executes in the context of our own domain. Besides, given that our code would still be at least one function call removed from the actual user action event, this approach is likely to fail with less sophisticated popup blockers.

Our solution? Display a message inside the Contacts control to inform the user that data had been received from the web app, and prompt the user to "Click here to review the data". This solution has the downside of introducing an extra user click into the chain of events, but that click is what enables us to display the popup window from our JavaScript running in the context of our Microsoft domain without offending the popup blockers.

So, we should allow some measure of understanding for a web app that stumbles into popup blockers unexpectedly. The web developer is only guilty of a little ignorance and lack of testing.

But a web site that actively instructs you to disable popup blockers to use their site? This is where making ignorance into corporate policy has become easier than understanding the problem and its usually trivial solution. Show them no mercy!