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.
So long, and thanks for all the fish!