Windows Live Quantum Mechanics

Leaving Microsoft

MSDNArchive — Sat, 06 Oct 2007 00:17:00 GMT

As I've been wrapping up our 2nd generation cross-domain in-browser communication channel API, I've been nosing around and thinking about what my next project should be. There's no shortage of tasks to do in Windows Live, and I had a few leads for interesting projects elsewhere within Microsoft as well.

Just as I cleared my mental desk to consider these options in detail, suddenly their came a tapping as if someone gently rapping, rapping on my chamber door. It was a startup calling, trying to seduce me into doing something rash. I've been approached by startups before, but most are easy to dismiss because they have no funding. No matter how good the idea, I can't afford to work for IOUs. This one was different. Disruptive ideas, razor sharp team, and recently funded by Kleiner Perkins. Well that's different.

As fate would have it, my next gig will be at CoolIris, building browser plugins that are one part eye candy an two parts antimatter disrupter.

While I will be leaving the Microsoft payroll, I won't be leaving the Windows Live arena. I'm moving from the service producer to the service consumer side of the field. CoolIris will quickly need user logins, address books, photos, and storage, and I will certainly make sure they are aware of Windows Live's service offerings. We should definitely leverage rather than build out infrastructure.

The cross-domain communications article series will continue, "posthumously" if you will. The siloed domain lowering technique mentioned in the last article is on hold pending clearance of some internal paperwork. It will be published ASAP after the paperwork is sorted out.

The last article in the series (for now) will document the InterFrame Messaging channel API that we've been working on as a by-product of our development of the Windows Live Contacts control. That article is on hold pending the release of the IFM channel API, which is on track for Real Soon Now. Keep an eye on dev.live.com for announcements.

I've started a new blog on my personal domain, www.dannythorpe.com. For uninterrupted blatherings, please update your RSS readers to use the new address and RSS feed.

So long, and thanks for all the fish!

Cross-Domain Communication Using Domain Lowering

MSDNArchive — Fri, 28 Sep 2007 08:52:28 GMT

More than a few blog posts ago I stated my intent to publish a series of articles on cross-domain communication techniques. More time has passed than I had intended, but at last here is the start of that series of articles. The series will explore progressively more advanced cross-domain techniques as well as their strengths and weaknesses, culminating in an announcement about stuff we've been working on that I think you'll find interesting.

Cross-domain communication is usually discussed in the context of a browser client communicating to a web server that is different than the domain of the web page currently shown in the browser. The browser client displays a page from server foo.com, and that page tries to access data on server bar.com. This is forbidden by the same-origin browser security policy because bar.com isn't foo.com.

Server Side Proxy

One relatively simple way to resolve this is to have the browser page request data from the page's web server, and have the web server relay that request to the actual third party server. The browser displays a page from foo.com, and that page makes a data request to foo.com which foo.com relays to bar.com. Bar.com replies to foo.com, and foo.com forwards that response on to the browser client page to complete the circuit.

While this solution is simple and quite widespread today, it has some significant problems:

Scalability and Network costs: The request and response travel across your server's network twice. Request in, request out, response in, response out. Traffic on your server network grows four times faster than growth of your application use. That means you'll reach network saturation four times sooner than with other techniques, and you'll pay four times more (in server network traffic costs) for the privilege.
Impersonating the user: When your foo.com server makes a request to bar.com seeking data for the user, you're essentially impersonating the end user. If the data on bar.com requires any sort of user identification or authorization, your server side proxy suddenly jumps from super simple to super difficult. It's easy enough to ask the user to log in to bar.com, but your foo.com can't see anything that goes on in bar.com. In particular, foo.com cannot see whatever browser cookies that bar.com sets to indicate logged in state. Thus, it will be next to impossible for foo.com to present the appropriate cookies or credentials in its http request to bar.com to make bar.com believe that the request is coming from the legitimate user. And this should be difficult - this is nothing short of a man-in-the-middle attack on bar.com's security!

So, server side proxies are a quick and dirty way to toss anonymous data around, but they don't scale well and they hit a wall when the data requires authentication.

Web Sites With Subdomains

Web sites and web applications generally start out as simple beasts running on a single web domain (www.foo.com). As the site grows in functionality and complexity, the incentives to break that site up into subdomains (downloads.foo.com, feedback.food.com, images.foo.com) grows as well. Perhaps your web site has a download area that needs to be optimized for large file transfers. That would probably be easier to fine tune as a server or cluster dedicated to that function than to try to tune the entire web site for large file downloads.

Subdomains often sprout as a byproduct of a company's internal structure. It takes a lot more effort to coordinate updates to one central server shared by multiple departments on different schedules than for a department to own their own subdomain, nicely isolated from the rest of the company's constant revisions.

Double Edged Sword

Domain isolation is convenient to let you get your work done independently of the noise going on in the rest of the company's web presence, but also presents a new problem: web pages served from your subdomain cannot share information with web pages served from other subdomains of your company. If the user logs in to your company's main page, the browser cookies representing that login state are not accessible to your subdomain.

Lowering the Domain Barrier

The major browsers support a technique around this quandary, to allow subdomains to operate as equals within a common shared context. The HTML document object has a domain property which normally reflects the complete domain name of the server from which the HTML document was loaded. The browser will allow you to assign a subset of the current domain name to the document.domain property to indicate that you wish for the HTML document to be treated as though it were loaded from the parent domain.

So, an HTML page served from downloads.foo.com can assign document.domain = "foo.com" in a JavaScript code block. From that point forward, browser domain security checks will treat that page as a peer of any page in the foo.com domain.

The browser will (should) only allow you to change the document.domain to a less specific version of your current domain. one.two.three.foo.com could be lowered to foo.com, or could be lowered to three.foo.com.

The browser should not allow assignment of a top-level domain (domain suffix) to document.domain. You should not be able to change a document domain from "one.foo.com" to "com". There have been browser bugs in this area in the past where a browser implementer mistakenly interpreted "top level domain" to mean "the bit of the domain after the last dot". ".com", ".edu", and ".org" are top level domains, but ".co.uk" and ".co.jp" are TLDs also.

The browsers will not allow you to raise the domain of an HTML document to something more specific than its domain of origin, nor allow lateral domain shuttling. Changing document.domain from "two.foo.com" to one.two.foo.com" is forbidden. Changing a document.domain from "one.foo.com" to "two.foo.com" is forbidden.

Irreversible (Mostly)

Firefox 1.5 and 2.0 will not allow you to assign a domain name that is more specific than the document's current domain name under any circumstances. Once you lower one.foo.com to foo.com, it's stuck at foo.com forever. The only way to clear that state is to reload the page.

IE6 and IE7 will allow you to raise a document's domain back to it's actual domain of origin. If a page was served from one.foo.com, and you lower it to foo.com, IE will let you raise it back to one.foo.com. However, I've seen some instabilities and inconsistencies in the aftermath of "raising shields", so I don't recommend relying on this behavior. Since Firefox doesn't allow restoring domains to their original values, you should ignore the fact that IE sort of does allow it.

Bridging Silos Via Least Common Denominators

When an HTML document's domain is lowered to a parent domain, the security context and JavaScript symbol space of that document joins the security context and JavaScript symbol space of any and all pages that are also in the parent domain. JavaScript in your page served from one.foo.com and lowered to foo.com can access JavaScript functions and variables defined in other pages whose domain is foo.com, and visa-versa.

So, if you have pages on one.foo.com that would like to interoperate with pages on two.foo.com, you can use domain lowering to pull down the domain barriers just enough to allow them to talk to each other, but still provide domain protections against third parties trying to steal or corrupt the internal state of your web app. Place a JavaScript block at the top of each page in the "one" and "two" subdomains which assigns document.domain = "foo.com" and you're good to go. All the pages will operate as though they were served from the same domain, and can access anything in each other's DOMs and JavaScript symbol space.

One or the Other, Not Both

Note that once your one.foo.com page has been lowered into the parent domain, your HTML and JavaScript code loses all access to DOMs and JavaScript data in any other pages that are still in the original one.foo.com subdomain. A web page can only be in one domain context or the other, not both.

Interesting Inconsistencies

Domain lowering applies only to the DOM and JavaScript sandboxes. Parts (actually, nearly all) of the browser execute in native machine code outside the browser security sandbox. Native objects exposed to JavaScript in the sandbox are largely on their own to implement appropriate security checks on operations initiated by JavaScript. JavaScript can't access the local file system, for example, but if the user installs an ActiveX control for IE or a browser plugin for Firefox that allows local file access, and that extension declares itself safe for scripting, then JavaScript could use that control to access files on the local file system.

In both IE and Firefox, XMLHttpRequest (XHR) is a native object exposed to JavaScript. This is pretty obvious in IE6 since you have to construct the object using ActiveXObject; in Firefox you can deduce that the XHR is a native object from the phrasing of some error messages and error behaviors while the browser goes down in flames.

XHR is restricted to connecting only to the current HTML page's domain of origin. Domain lowering applies only to the browser sandbox. XHR operates outside the browser sandbox, enforcing same-origin domain policy on its own. This leads to an interesting - and valuable - inconsistency:

XMLHttpRequest is not affected by domain lowering.

This means you can actually have one foot in each domain: Your JavaScript executes in the context of the lowered subdomain (foo.com), but XHR requests made by your JavaScript are held to the domain restriction of the page's original subdomain (one.foo.com). XHR doesn't know anything about document.domain.

If you're trying to get your JavaScript to open an XHR to a resource on foo.com, this can be infuriating because XHR won't do it. You have to refer to an HTML page served from foo.com in order to get XHR to open a connection to foo.com.

The Money Shot

This inconsistency in the handling of document.domain enforcement/awareness makes the following scenario possible: The logic of your web app runs in the context of a page loaded from one.foo.com, and you want to XHR load data from two.foo.com.

Here's how you do that:

Make your html page A served from one.foo.com lower its document.domain to foo.com
Place an html page B on two.foo.com, and have it lower its document.domain to foo.com early in its load cycle. (A JavaScript statement in global scope in the <head> section is fine).
Implement a function GetData(callback) on this page that constructs an XHR request to load the desired data from two.foo.com. Wire up the XHR onReadyStateChanged to process the data completion using a function implemented in B.html, and in that function pass the received data to the callback function passed into GetData().
Insert an invisible (1x1 pixel) iframe on page A and set its src to http://two.foo.com/B.html
After page A has fully loaded, and page B in the iframe has loaded, JavaScript code in page A can call the GetData() function in page B through the iframe element: bframe.window.GetData(mycallback)

Believe it or not, this works. Domain lowering allows JavaScript to call between A and B, and the fact that B is served from two.foo.com allows the XHR request implemented in B to access two.foo.com.

Here Be Pixies. (Try Not To Piss Them Off)

The path through this murky realm is neither straight nor wide. If you take liberties or shortcuts with this recipe, be careful to test your code thoroughly on multiple browsers. Chances are high that any deviation will lead to failure on one of the browsers.

IE is fairly flexible in this area. You don't actually have to implement the GetData function in the B page. You can just construct in the A context an XHR object type from the B context and use it directly in the A context. ( var xhr = new bframe.window.XMLHttpRequest() ) For IE, the B page need only lower the domain to foo.com. After that, all the driving can be done from A.

Firefox is more particular about this technique. Firefox will allow you to construct an instance of the B XHR in the context of A, but you'll get access denied or weirder errors when you try to call the methods of the B XHR from the context of A. Firefox gets confused when you call native object methods across these convoluted domain bridges, but calling JavaScript functions and methods works fine on either side of the context boundary. Once the JavaScript call context gets from A to B, then the native object method calls will work.

This is also why step 3 above mandates that the XHR onReadyStateChange event handler should be wired to a function implemented in the B page - the native XHR object operating in the B context may have difficulty firing an event wired to a function in the A page context.

The Downside to Homogeneity

For domain lowering to work between two subdomains, both sides have to "lower their shields" to a common middle ground. As this technique catches on across departments and their corresponding subdomains, you can quickly reach a point where just about all the subdomains on the corporate web have provisions to lower their domain to the common corporate parent domain.

This is convenient and quite powerful for building web apps that can access data bits from all across the company. The problem is that it weakens your corporate defenses across the board. If just one of the subdomain silos were compromised and an attacker were able to inject malicious JavaScript to execute in the browser context of that compromised subdomain, that malicious code would have easy access to every subdomain across the company that lowers its domain to foo.com.

This risk grows with scale. The more subdomains you have that routinely lower their domains to the common ground, the greater the risk that one of them may be compromisable and serve as a beachhead to your entire network.

Tune In Next Time

There is a way to mitigate this weakest link risk such that an attacker compromising a weak subdomain does not get access to everything. This requires inverting some of the relationships presented in this article and making the silos deeper rather than shallower. I'll cover "Siloed Domain Lowering" in my next cross-domain article.

TMobile HotSpot at Home Phones Get Smarter

MSDNArchive — Fri, 28 Sep 2007 03:07:28 GMT

TMobile announced this week the addition of the Blackberry 8230 "Curve" to the list of cell phones supported by TMobile's HotSpot@Home WiFi phone service.

This is a big step up in handset functionality over the minimalistic handsets that the service launched with earlier this year. I'm very tempted to jump in, since the Blackberry can do web surfing and web email that I crave, but of course there are just two little things that would make it just perfect: a smaller smartphone handset (the Curve is almost as wide as it is tall) and a smartphone handset that can run .NET CF applications.

Not that I've written any .NET CF apps lately, mind you, but just because I like having that option at my disposal. I've endured locked phones before where the only thing you can do with the phone is what the cellular provider says you can do with it (thanks, Nextel) and I don't intend to go through that again.

Smartphone with WiFi calling... Tempting, very tempting...

Halo 3 Launched!

MSDNArchive — Mon, 24 Sep 2007 21:15:55 GMT

Halo 3 has officially hit the streets! Besides the game itself, check out the supporting info on the web, which happens to be implemented in Silverlight: http://www.microsoft.com/silverlight/halo3.aspx

Having been out of the loop on the whole Halo series progression, I found the backstory and character summaries for Halo 3 very informative.

MIX07 UK Podcast with Craig Murphy

MSDNArchive — 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

MSDNArchive — 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

MSDNArchive — 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!

The Casual Traveler

MSDNArchive — Tue, 11 Sep 2007 13:29:26 GMT

Angus laments getting hit unusually hard by jet lag on this UK trip. This is particularly amusing considering he's recently imported to Redmond from Australia and generally has far too much energy to safely occupy one body. I suspect he owns an espresso machine. Possibly even USB powered and in his bag.

Angus's criteria for professional traveler struck me as odd. Carry-on luggage? What a drag. I try to get rid of the bag as quickly as possible so I can enjoy the rest of the trip without wrenching a shoulder out of socket. Alas, the laptop backpack is inescapable, but at least on personal travel I can trade the 10 pound company brick for something a little more svelte - my 1.8 pound Sony X505. Sure, waiting for baggage claim can be a drag, but that's what frequent flyer program expedited baggage services are for. Besides, if you're picking up a rental car you can usually take care of that checkin and key pickup while the baggage handlers are getting your bag to the carousel.

Running down the gangway to get to the head of the passport control line? Nah. A casual stroll gets you there almost as fast, plus you get free entertainment watching the rat race rushing by.

Rely on plastic rather than local currency? Absolutely. All major purchases can be done on the card in any modern location - including magazines and snacks at airport kiosks. It's still a good idea to have a little cash in pocket change for the impromptu street vendor purchase. Skip the outrageous transaction fees and exchange rates at the Cambio kiosks at the airport. Just find a cash machine on the Cirrus, Visa, or other US bank network and make an ATM withdrawal in local currency. The exchange rates tend to be more reasonable and no transaction fees (from my bank, anyway).

I've also noticed that the density of currency exchange kiosks in an airport is inversely proportional to the number of ATM machines. Coincidence? Hmm. Gatwick is paved with exchange kiosks, but you'll be lucky to find an ATM before you get to Victoria station. Schiphol has a much better proportion of ATM machines.

Overall, I guess I don't think of myself as a "professional traveler". I do travel quite a bit, and a lot of it is work related, but I'm definitely not in the power traveler category. Even packing for most trips is a non-event. Count the number of days away, grab a matching number of socks, underwear, shirts, etc. Matching socks a plus. Oh, and pants. Pants good.

Making packing and trip preparation a non-event has become a bit of a sport at home. Lack of preflight checks and rechecks drives my wife nuts, which is entertaining in its own right.

However, the wife will have the last laugh on this trip. It's been a long time since I've forgotten to pack something important, but on this trip I've left quite a few items at home - probably laid out on the bed but didn't make it into the suitcase. The dog probably grabbed them. Ya, that's it.

The most irritating miss was forgetting my (equally svelte) camera. I made a point of moving it from its home in the laptop backpack to the charger the night before departure to make sure it had a full charge for the trip. It didn't make it back into the backpack. Next time, I'll just stick to the regular routine of packing the camera and charger and topping it up in the hotel on arrival.

For critical trips, I'll do my homework and look up maps and so forth prior to departure. For most trips, though, I just wing it. Get a rail pass at the airport and figure out how to get to where I'm going by reading the rail map on the train. Occasionally step off the train to take a look around, and step back on the next train a few (5, 10, 30) minutes later. Pay close attention to next train times if you venture out into the suburbs, as trains generally aren't as frequent in low density areas as they are downtown.

Taking it in as it happens makes the trip more interesting than racing around with blinders on. It's a great way to make discoveries that aren't in any travel brochure.

Blogging at ReMix07 London

MSDNArchive — Tue, 11 Sep 2007 12:00:50 GMT

I'm sitting next to Angus in the back row of the ReMix07 London keynote. Angus is blogging in Windows Live Writer, and the guy on the other side of him is blogging in Windows Live Writer. Everyone loves a parade, so here I am blogging in Windows Live Writer, too.

It's times like these when I wish I had remembered to pack my camera.

Halo 3 Promo Videos Running on Silverlight Streaming

MSDNArchive — 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

MSDNArchive — 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.

Where Have We Heard That Before?

MSDNArchive — Sat, 25 Aug 2007 00:55:27 GMT

Yesterday the Seattle Times ran an article about Penny Arcade and the overnight success of the Penny Arcade Expo. I had to laugh a little when the article used the words "imploded" and "E3" in the same sentence. I used pretty much the same pairing of words back in my January 2007 Events Calendar post.

The Seattle Times article has more timely data than that January post, naturally. PAX2007 is expecting some 30,000 people through its doors this weekend. Thirty Thousand! Jiminy Cricket! PAX2005 was only 1500 or so people (and 3x the expected turnout even then).

E3 Dies Again

In other news, FiringSquad reports that the new event that came out of nowhere, E for All Expo, is having trouble attracting major exhibitors. Sony is not interested, Microsoft is noncommittal. The only player signed up so far is Nintendo. E for All Expo is the brainchild of IDC, the very makers and destroyers of the late great E3 Expo. If this is IDC's attempt to rectify their choice to kill consumer access to E3, it sounds like the vendors are not playing ball. And why should they? IDC has a terrible track record with the consumer market.

Windows Live SkyDrive

MSDNArchive — 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!

MSDNArchive — 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!

Black Pixels Cost Less?

MSDNArchive — Fri, 03 Aug 2007 21:15:00 GMT

I was recently introduced to a Google search wrapper called www.blackle.com. It's sole claim to fame is that it displays a Google-like search page, but with a background color of black. Why? Blackle.com claims that black pixels require less energy to display than white pixels, so if everyone who uses Google were to see a black screen instead of white, the world would collectively save upwards of "750 megawatt-hours per year" of electricity.

Those are grand claims. While the sentiment to save energy and reduce environmental impact is well placed, I was skeptical.

So, I dug out my only CRT monitor from the closet and hooked it up to my Kill-A-Watt power meter and my laptop's external video connector. For a white screen, I used an Outlook message editor window, maximized. For a black screen, I used a cmd prompt window, maximized.

Nokia 447x 21 inch CRT: Black screen: 75 watts. White screen: 101 watts.

On the surface, these results appear to support the claims and pie-in-the-sky global estimates.

However, there's a catch.

Look at the results for an LCD monitor:

Samsung 21 inch LCD model 204B: Black screen: 36 watts. White screen: 36 watts.

LCD screens use fluorescent (or recently, LED) backlights to illuminate the screen. The backlights consume the same amount of power regardless of whether the LCD crystals are showing black pixels or white pixels. If anything, LCDs have to work harder to show black pixels because they are flooded with white light. In a CRT, black is the default state and the CRT has to work to make a white pixel.

LCD screens have been outselling CRTs for many years now. Laptops surpassed desktop sales years ago. I don't know if there are already more LCD's in the field than CRTs, but it's clearly the case that LCDs are growing while CRTs are in decline. Odds are, you're reading this text on an LCD screen.

While it's true that a black pixels consumes less power than a white pixels on a CRT screen, pixel color has no effect on LCD power consumption. Given that LCDs are a large and growing (and possibly majority) portion of the global monitor population, the power savings claimed by blackle.com is a case of diminishing returns.

Custom Colors in the Windows Live Web Controls

MSDNArchive — 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!

T-Mobile Rolls Out WiFi Cell Support

MSDNArchive — Fri, 29 Jun 2007 00:27:26 GMT

At last! T-Mobile has rolled out their long-awaited HotSpot @Home service nationwide. This enables you to make and receive cellphone calls over WiFi networks when in range of a WiFi access point and seamlessly transfer calls between WiFi and cellular networks. The service also includes WiFi access through thousands of T-Mobile HotSpots at cafes and public places across the US.

The big win is that this should go a long way towards addressing poor cellular signal strength inside homes and office buildings. I can get one or two bars of radio signal in the yard at home, but barely one bar inside the house, and only in one room, with one arm out the window. As for WiFi, our house virtually glows with A and G.

The only caveat to this new service is that it only works with two specially equipped phones offered by T-Mobile, and the phone features are nothing to write home about. No smartphones are supported yet. And apparently, even smartphones that already have WiFi hardware (such as the Dash) are not supported by the HotSpot @Home service. PhoneScoop has an in depth review.

As much as I want the @Home WiFi service, I can't make the leap until more capable handsets are supported. My wife wouldn't be offended by lack of handset features, though, so I might switch hers over to HotSpot @Home first. If it works well over WiFi at home, we might actually retire our VOIP service in favor of T-Mobile HotSpot @Home.

ZeroGravity: Casual Gaming in Silverlight

MSDNArchive — Wed, 27 Jun 2007 23:35:25 GMT

Looks like the folks at terralever are going full-bore on Silverlight: They've implemented a delightfully addictive puzzle game called ZeroGravity using the Silverlight 1.1 Alpha runtime. Check it out!

It'll be interesting to see how long before my #5 high score (9997) rolls out of the top ten.

via Tim Heuer

LinkedIn to Add an API?

MSDNArchive — Mon, 25 Jun 2007 19:38:39 GMT

Dan Farber writes that LinkedIn's Chairman, Reid Hoffman, has commented that he plans to roll out developer APIs to access the LinkedIn contacts database. Great news!

The downside: It won't be ready until 2008. Bummer. How much further will the other social networks have outpaced LinkedIn by then?

Secure Cross-Domain Communication: The Architecture Journal

MSDNArchive — 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

MSDNArchive — 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

MSDNArchive — 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!

Undisclosed Browser Technology

MSDNArchive — Thu, 31 May 2007 20:29:38 GMT

When people ask what I worked on at Google and I answer "undisclosed browser technology", I think some folks think I'm just being coy or obnoxious. The truth is, I'm required to say that publicly and privately until Google publicly announces the technology or its derivatives.

Well, that day has finally come. Yesterday Google announced the Google Gears API, a set of browser plugins that provide client-side local storage and related services.

I was a founding member of that project and helped draft the specs and write the early iterations through proof of concept and functional prototype stages. They've made a lot of fit & finish improvements over the past year (and a perhaps a few changes in focus to navigate Google's internal politics), but I can still recognize a few bits here and there.

Congratulations to my old teammates for getting Gears out the door: Linus Upson, Mike Tsao, Michael Nordman, Eric Arvidsson, Aaron Boodman and the rest of the gearheads! ;>

Microsoft Surface

MSDNArchive — Wed, 30 May 2007 23:11:19 GMT

You've got to see it to believe it: http://www.microsoft.com/surface/

Mmmm-mmm good.

It may be time soon to dust off those great old Avalon Hill board games and look at implementing them on this table - without the thousands of chit markers. Twilight Imperium, anyone? Or perhaps Settlers of Cataan?

A Cross-Domain Silverlight Channel 9 VideoRSS Player

MSDNArchive — 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!