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

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

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 pa

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.