Recently I asked one of the Javascript devs on the Windows Live Spaces team to review the code for some of my gadgets to see if he could point out areas for improvement. One thing he mentioned was that there were a ton of memory leaks in my gadgets. This took me by surprise since the thought of a memory leak in some AJAX code running in a browser sounded like a throwback to the days of writing apps in C/C++. So I went back and took a look at the Windows Live gadget SDK, and sure as hell there was a section of the documentation entitled Avoiding Memory Leaks which states

Memory leaks are the number one contributor to poor performance for AJAX-style websites. Often code that appears to be written correctly will turn out to be the source of a massive memory leak, and these leaks can be very difficult to track down. Luckily, there are a few simple guidelines which can help you avoid most memory leaks. The Live.com developers follow these rules religiously, and recommend that you do the same when implementing Gadgets.

• Make sure you null any references to DOM elements (and other bindings for good measure) in dispose().
• Call the base dispose method at the end of your dispose method. (conversely, call the base initialize at the beginning of your initialize method)
• Detach all events that you attach.
• For any temp DOM element vars created while constructing the DOM, null the temp var before exiting the method.
• Any function parameters that are DOM elements coming in should be nulled before returning from the method.

There are a number of websites and blog entries that document approaches for identifying and fixing memory leaks in AJAX applications. One such helpful site can be found here.

A great way to see whether your Gadget is leaking memory is to use the following URL to load your Gadget: http://gadgets.start.com/gadget.aspx?manifestUrl=gadgetManifestUrl. Open Task Manager in Windows and monitor the memory usage of the Internet Explorer window. Keep reloading the Gadget in Internet Explorer to see if the memory usage increases over time. If the memory usage increases, it is indicative that your Gadget is leaking memory.

This is the entirety of the documentation on avoiding memory leaks in Windows Live gadgets. Granted there is some useful information in the blog post referenced from the SDK. The post implies that memory leaks in AJAX code are an Internet Explorer problem as opposed to a general browser issue. 

Most of the guidelines in the above excerpt were pretty straightforward except for the one about detaching all events you attach. I wasn't sure how event handling differed between Firefox and IE (the only browsers I test gadgets on) so I started down the path of doing some research. and this led me to a number of informative posts on Quirksmode. They include

1. Traditional event registration model
   
2. Advanced event registration models
   
3. addEvent() considered harmful
   

The information in the above pages is worth its weight in gold if you're a Javascript developer. I can't believe I spent all this time without ever reading Quirksmode. The Windows Live gadgets team would be doing gadgets developers a lot of favors by including the above links to their documentation.

There is also an interesting observation about the end user perceptions about who's to blame for badly written gadgets. The comment about memory leaks in my gadgets answered the question of why Internet Explorer uses as much as 200MB of memory when running my Live.com start page. At first, I assumed the problem was with Live.com and then after switching browsers to Firefox I saw some improvement and then assumed the problem was with IE. It never crossed my mind that the problem was the poor coding in the gadgets on my page. This may just be because I was the author of many of the gadgets on my page but I suspect that when the average end user hits problems with poorly written gadgets causing issues with Live.com or Windows Live Spaces pages, Microsoft is the entity that gets the blame not the gadget developers.

Just like with Windows®, poorly written applications often reflect badly on the platform and not just the application. Interesting food for thought if you are interested in building Web platforms. 

The Windows Live Wifi team has an introductory blog post entitled Hello World... which is excerpted below

I’m Stefan Weitz, director of planning for Windows Live WiFi. The team has been developing Windows Live WiFi Center over the past few months and it’s now time to let others experiment with it. The beta is currently limited to 5,000 people but will open up more broadly in the coming months.  If you are interested in participating please email your Windows Live ID (ex. JaneDoe@hotmail.com) to BellBeta@microsoft.com and we’ll get you on the list of interested parties.

Getting online in a WiFi world
Windows Live is all about unifying our customer’s online experience.  Well, let’s face it – you need to be connected (in one way or another) to have that world unified :).  The Windows Live WiFi Center is all about helping people get connected in a secure way – it’s essentially our first step at creating an integrated software solution that helps people find and securely connect to wireless networks around the world.  The Windows Live WiFi Center has a number of great features in this beta version (hint: beta = more features are coming soon…).

 ·         Hotspot locator:  Provides you with the ability to search for free and fee-based wireless networks in countries around the world.  The locator shows you the address, description, available amenities, service providers and shows you a map of the location.

 ·         Network Management: Helps you see what networks are available and makes it easy to get technical information about them, including their security configuration, signal strength, etc.  In addition, you can tag networks as ‘favorites’ for future connections, track connection history, and manage network preferences. 

 ·         Security: Our built-in security, using VPN technology, allows you to secure a wireless Internet connection on unsecured networks like those in hotels and coffee shops.  This security feature comes free with the Windows Live WiFi Center product. 

Sounds pretty sweet. I've known this product was coming but hadn't tried it out yet. Looks like I need to get hooked up with the beta. The HotSpot Locator sounds particularly interesting to me.

Nick Gall has a blog post entitled What were we thinking? where he writes

It just struck me, after 5+ years of analyzing the ins and outs of SOAP, how little need there has turned out to be for the SOAP binding model (i.e., binding SOAP onto various "transport" protocols). If some endpoint is going to go to all the trouble of enabling processing of URIs and XML (a prerequisite for processing the SOAP envelope), what are the chances that said endpoint would not go ahead and enable HTTP processing? The scenario of a mainframe endpoint that is able to process a SOAP envelope, but is unable to process HTTP to receive the envelope strikes me as ludicrous.
...
So who really cares that SOAP is able to be bound to MQ or IIOP or SMTP, today? Apparently, very few--since there has been virtually no progress towards standardizing any SOAP binding other than to HTTP for years.
...
Accordingly, it seems to me that the WS-* stack could be made a lot less complex for the average developer if the SOAP and WSDL binding models were simply deprecated and replaced with simpler "native HTTP" binding

This is one of those blog posts where I simultaneously agree and disagree with the author. I agree that a lot of the complexity in WS-*/SOAP/WSDL/etc has to do with the notion of "protocol independence". As I mentioned in a previous post entitled Protocol Independence is a Leaky Abstraction, the way SOAP and the various WS-* technologies achieve protocol independence is by basically ignoring the capabilities of the Web (i.e. HTTP and URIs) and re-inventing them in various WS-* specifications. This leads to a lot of unnecessary complexity and layering when you are already using HTTP as the transport protocol (i.e. the most common usage of SOAP).

On the flip side, there is something to be said for being able to use one distributed application model and support multiple protocols. For example, if you read the Windows Communication Foundation whitepaper you'll see it mentioned that WCF supports sending messages via HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ). I've actually been working on using this functionality in some of our internal Windows Live platform services since the performance benefits of using TCP for communications over SOAP/HTTP are considerable. However we'll still have SOAP/HTTP end points since that is the lowest common denominator that SOAP-based services that interact with our services understand. In addition, I'd like to see some straight up PlainOldXml/HTTP or RESTful end points as well.

One of the main problems we've faced in our evaluation of moving to multiprotocol SOAP services is how much of a leaky abstraction the "protocol independent" nature of SOAP tends to be in real life. My favorite issue thus far is that we actually use HTTP redirects in our current SOAP web services. Guess what? There is no "protocol independent" WS-Redirect specification. So we have to roll our own solution for non-HTTP protocols.

We've hit a couple of other minor issues but in general the support we've gotten from Omri, Doug Purdy and others on the WCF team has been great. In fact, I've started to lose some of my skepticism about the WS-* family of technologies. I still think they are overkill for the Web though. ;)

It looks like I'm now writing a Windows Live gadget every week. My latest gadget is a port of the Flickr badge to a Windows Live gadget. It's in the approval pipeline and should show up under the list of gadgets I've written in the next day or so. To get the gadget working, I had to use the Flickr API. Specifically, I used the flickr.people.findByUsername method to convert a username to an internal Flickr ID. Ironically Coincidentally, I had recently read something by Alex Bosworth criticizing this very aspect of the Flickr API in his post How To Provide A Web API where he wrote

Simple also means don’t be too abstract. Flickr for example chooses in its API to require the use of its internal ids for all API calls. This means for example that every call to find information about a user requires a call first to find the internal id of the user. Del.icio.us on the other hand just requires visible names, in fact internal ids are hidden everywhere.

Actually, it's much worse than this. It seems that Flickr is inconsistent in how it maps user names back to internal IDs. For example, take Mike Torres who has 'mtorres' as his Flickr ID. I can access his Flickr photos by going to http://flickr.com/photos/mtorres. When I use the Flickr API explorer for flickr.people.findByUsername and pass in 'mtorres' as the username I get back the following ID; 25553748@N00. When I go to http://flickr.com/photos/25553748@N00 I end up going to some other person's page who seems to be named 'mtorres' as well.

However when I plug "Mike Torres" into the flickr.people.findByUsername method instead of 'mtorres' I get '37996581086@N01' which turns out to be the right ID since going to http://www.flickr.com/photos/37996581086@N01 takes me to the same page as http://flickr.com/photos/mtorres. Weird.

Perhaps this is a naming collision caused by the merging of Flickr & Yahoo! IDs?

Over the weekend I blogged that Kiko was an example of sprinkling AJAX on old ideas that had failed in the 1990s. I found an even better example from a blog post by Richard MacManus entitled Ex-Googler starts Webwag, new personalized start page where he writes

"According to Poisson, Webwag’s revenue streams will include affiliate marketing – something Netvibes is doing via Kelkoo - and B2B deals, an as yet unexplored area. Chris previously suggested that white labelling this technology is one key revenue opportunity for these firms to consider.

Poisson said: "As Web 2.0 develops over the next three three to five years, two things will remain. Firstly, everyone will have their own blog, and over 75% of people will have their own personalised start pages.

"My belief is the big search portals (My Yahoo etc) will get 50% of that market, and 50% will be taken by three to four independents.”"

Personally I think that 50% figure for independents is too ambitious. I also question his claim that 75% of people will have a start page in 3-5 years, unless you count the likes of Yahoo.com as a 'personalized start page' (actually I suspect the distinction will be moot in 5 years time).

If someone would have told me that AJAX versions of My Yahoo! (i.e. a portal homepage) except with none of the integration with a family of websites that a portal provides would be a hot startup idea I'd have laughed them out of my office. This market was saturated five years ago. The thought that adding drag & drop to a portal homepage and not having any rich integration with a family of sites is a viable business seems pretty absurd to me. The barrier to entry is pretty much zero, all you need to do is grab the Yahoo! Javascript UI library and write some code to parse RSS feeds to get started. That's besides the fact that the portal homepage is primarily a means to an end since they are there to encourage people to stick on the site and use other services (i.e. search) and not the core product in itself.

The quote that 75% of people will have a personalized start page is the best part though. As if the lack of AJAX and drag & drop is the reason that 75% of the population don't have My Yahoo!, My MSN or My AOL pages. Yeah, right. 

This reminds me of a conversation I was having with Eric Fleischman about blogging and RSS becoming mainstream yesterday. We agreed that blogging is already mainstream because everyone has a MySpace from politicians and school teachers to movie stars and DJs. On the other hand, I didn't think subscribing to feeds in a conventional aggregator would ever become used by a widespread percentage of the population. Subscribing to feeds seems cool to geeks because it solves a geek problem; having too many sources of information to keep track of and optimizing how this is done. The average person doesn't think it's cool to be able to keep track of 10 - 20 websites a day using a some tool because they aren't interested in 10 - 20 websites on a daily basis in the first place. I'm sure a light sprinkling of AJAX can solve that problem as well.

*sprinkle* *sprinkle* *sprinkle*

Matt Mullenweg has a blog post entitled MSN Spaces Numbers where he writes

Scoble has been questioning the claimed numbers of MSN Spaces and somehow the conversation got sidetracked in the technicalities of “what’s a blog?” I’m not sure what Microsoft hopes to gain by inflating their numbers so much, now claiming 70 million “blogs”, but it’s interesting to note back in March they were claiming 123 million blogs at SxSW (Flickr photo of their booth). Of course that was like 2 name changes and reorgs ago. Maybe 50 million people left the service?

I wasn't planning to blog about the recent round of player hating on Windows Live spaces certain bloggers but the above claim by Matt Mullenweg that we are 'inflating' our numbers really got my goat.

First of all, the two numbers quoted above by Matt are unrelated metrics. The count of 123 million users is explained in the press release MSN Spaces Now Largest Blogging Service Worldwide which states that comScore Media Metrix has measured the service's reach as being 100 million unique vistors a month and this number is in addition to 20 million unique visitors from using the chinese version of MSN Spaces. The 70 million number is the number of blogs spaces that have been created since inception. This number isn't particularly interesting since it doesn't correlate to how many people are actually getting value out of the service.

For example, according to the LiveJournal statistics page their current statistics are

How many users, and how many of those are active?

• Total accounts: 10945719
• ... active in some way: 1870731
• ... that have ever updated: 7278240
• ... updating in last 30 days: 1164416
• ... updating in last 7 days: 679693
• ... updating in past 24 hours: 204465

According to those statistics only 1 out of 5 LiveJournal accounts is actually active. Of course, it would sound impressive to tout 11 million LiveJournal accounts even though the number of active accounts is much less. For that reason, the number of spaces on Windows Live Spaces isn't a particularly interesting metric to me nor is it to anyone I know who works on the product. We are more interested in the number of people who actually use our service and get value added to their lives by being able to share, discuss and communicate with their friends, families and total strangers. 

It's hard for me to believe that it's been five years since I was an intern at Microsoft. It's still fun to go back to read my blog posts about my Microsoft interview, my impressions halfway through the experience and my parting thoughts at the end if the experience. I've started thinking about my internship again because I'm going to be the mentor/manager of an intern in a couple of weeks and I've been taking strolls down memory lane trying to remember the experiences that made my internship worthwhile. 

My favorite experience is the story behind how I got the article Using the ECMA Standards: An Interview with Miguel de Icaza published on MSDN while I was still college and Microsoft had only said negative things about Miguel's Mono project up until that article was published.

It all started with an article on C|Net entitled Open source steps in to duplicate .Net which implied that Microsoft's licensing terms may not be favorable for Open Source implementations of the .NET Framework such as Mono and DotGNU. At the time, I thought it was rather two-faced of Microsoft to claim that the CLI and C# were going to be open ECMA standards but then threaten to prohibit Open Source implementations. So I fired of an ranting mail to the internal discussion list focused on the .NET Framework pointing out this inconsistency in Microsoft's position. At first, I got a bunch of replies smacking me down for daring to question Microsoft's strategy but after a couple of supportive mails from coworkers like Fadi Fakhouri, Omri Gazitt and a couple of others I eventually got routed to the right person. I met with Tony Goodhew who was quoted in the C|Net article and he set me straight. When I found out that this wasn't the case, I mentioned that it would be a great sign of goodwill to the Open Source community if Microsoft showed just how much they were supportive of such projects. Since I'd also gotten to know the author of the Dr. GUI columns on MSDN via another flame war email discussion, I had connections at MSDN and mentioned the idea to them as well. The MSDN folks liked the idea and when I pitched the idea to Miguel De Icaza he did as well. Although it only took a few email exchanges between Miguel and I to get the meat of the interview done, I didn't get the article completely edited and approved by MSDN until after my internship was done.

It was a pretty big deal for me when the article was published especially since Slashdot ran the story multiple times. The fact that I was just some punk intern and I got Microsoft to officially endorse Mono on MSDN was a big deal to me. The entire event made me appreciate Microsoft as a company and was a key factor in my decision to come to work for Microsoft full-time.

Now I'm trying to make sure I create an environment where the intern I'll be mentoring over the next few months can have similar experiences. If you are or have been an intern at Microsoft and don't mind sharing what rocked or sucked about your internship, I'd appreciate your comments.

The Windows Live Dev website has a new entry entitled New! Windows Live Contacts Gadget (beta) which states

Learn how, with nothing more than a little JavaScript, you can allow customers to use their Windows Live Contacts (Hotmail/Windows Live Mail and Messenger contacts) directly from your Web site.

To get started check out all of our developer info, the two working samples we’ve posted, and read the blog posts by one of the guys who developed it: Danny Thorpe.

What the gadget does is pretty simple yet powerful. It allows you to add a gadget to your page which logged-in Windows Live users can use to retrieve information about their Windows Live Messenger or Hotmail contacts and then input that data into your service. Think of it as adding a form fill or address auto-complete functionality to your site which uses that person's address book from Windows Live services to power it.

UPDATE: On inspecting the code it seems that my assertions in this post are incorrect. The change we made in the last release was not to enable Javascript by default. Instead it was to always ignore the Javascript setting chosen by the user for the newspaper view. This means that the current release of RSS Bandit is vulnerable to the majority of the flaws outlined in article linked below. I'll work on getting a release out that addresses this issue as soon as I can although this is complicated by the fact that we may not have a snapshot for the last release AND the first half of this week is very busy for me at work. If this security issue is a serious concern to you, my advice is to not use RSS Bandit until a release that addresses this issues is released or to switch to v1.3.0.29 of RSS Bandit which does honor the specified Security restrictions for the newspaper view.

A number of people have either sent me email or posted on the RSS Bandit forums asking whether RSS Bandit is vulnerable to the various issues raised in the article Blog feeds may carry security risk which states

LAS VEGAS--Reading blogs via popular RSS or Atom feeds may expose computer users to hacker attacks, a security expert warns.

Attackers could insert malicious JavaScript in content that is transferred to subscribers of data feeds that use the popular RSS (Really Simple Syndication) or Atom formats, Bob Auger, a security engineer with Web security company SPI Dynamics, said Thursday in a presentation at the Black Hat security event here.
...
"A large percentage of the readers I tested had some kind of an issue," he said. In his presentation, Auger listed Bloglines, RSS Reader, RSS Owl, Feed Demon, and Sharp Reader as vulnerable.

As protection, people could switch to a nonvulnerable reader. Also, feed publishers could ensure that their feeds don't include malicious JavaScript or any script at all, Auger said. Some services, however, rely on JavaScript to deliver ads in feeds, he noted.

To prevent this sorts of issues RSS Bandit allows users to optionally disable the running of Javascript, ActiveX or Java code in its Options dialog. Up until the last release we disabled Javascript, ActiveX and Java by default. However in the last release, we switched on Javascript by default to enable a particular features (i.e. specifically when you click on the envelope or flag on an item in the newspaper view to change the read or flagged state of an item). This means that by default RSS Bandit is vulnerable to the Javascript related issues mentioned in this article.

How to change this state of affairs is mentioned in the section of our user documentation entitled Changing the web browser security settings which has a screenshot of the Web Browser tab of the Options dialog where browser security restrictions can be set. 

Our users should configure the options to what best eases their security concerns. I'm still debating on what we need to do here in the long term but one thing I doubt we'll do is striping potentially malicious HTML tags since this seems to be a sledgehammer-like approach which may strip valid markup (e.g. <style> tags) from content. It's more likely that I'll remove our features that require enabling Javascript by default than go that route. I'd appreciate thoughts from our users on this.

Update: I was one of the developers contacted by James Snell and have failed to get back to him since I haven't gone through all of the tests he sent me yet.

Jon Udell proves again why he's my favorite technology journalist with his piece Why Microsoft should open XAML where he writes

The WPF/E runtime won’t implement all of XAML (XML Application Markup Language), a .Net language tuned for declarative application layout. But “the portion of XAML we’ve picked,” Gates told me, “will be everywhere, absolutely everywhere, and it has to be.”

“Everywhere” means the kind of ubiquity that the Flash player enjoys on Windows and Mac desktops, and to a lesser extent on Unix and handheld devices. And it sets up an arms race between Adobe and Microsoft, each giving away razors (that is, players) in order to sell blades (development tools).

Here’s a crazy idea: Open-source the WPF/E, endorse a Mono-based version, and make XAML an open standard. Why? Because an Adobe/Microsoft arms race ignores the real competition: Web 2.0, and the service infrastructure that supports it.

The HTML/JavaScript browser has been shown to be capable of tricks once thought impossible. Meanwhile, though, we’re moving inexorably toward so-called RIAs (rich Internet applications) that are defined, at least in part, by such declarative XML languages as Adobe’s MXML, Microsoft’s XAML, Mozilla’s XUL (XML User Interface Language), and a flock of other variations on the theme.

Imagine a world in which browsers are ubiquitous, yet balkanized by incompatible versions of HTML. That’s just where RIA players and their XML languages are taking us. Is there an alternative? Sure. Open XAML. There’s a stake in the ground that future historians could not forget.

When building rich internet applications today, the primary choices are AJAX and Flash. The reason that these are the two primary choices versus other options like Java, ActiveX, XUL, etc is their ubiquity. And AJAX is typically preferred over Flash because it doesn't require expensive development tools and there is the perception that AJAX is less proprietary than Flash.

Any technology that aims to compete with Flash and AJAX, has to be cross platform (i.e. works in Firefox and Internet Explorer at the minimum) and ubiquitous. Ubiquity can be gained either by taking advantage of the existing technologies within the browsers or by ensuring that the process for getting the runtimes on user's machines is seamless for end users. I have no doubt that Microsoft can eventually get development platforms ubiquitous on Windows. Earlier this week, I was reading a number of blog posts from people who tried out Windows Live Writer and don't remember anyone complaining about needing to have the .NET Framework installed to run it. It took a few years but it seems the .NET Framework is now on a majority of PCs running Windows if those blog posts is any indication. However it's taken a couple of years for that to happen.

If WPF/E is meant to be used in the same situations that AJAX and Flash are used today then it needs to give developers better advantages than the incumbents. If it was ubiquitous and cross platform, that would still just get it in the door. Jon Udell's idea to make it an Open platform on the other hand may take it to the tipping point. At the end of the day, Microsoft should favor building the ecosystem of rich internet applications that are accessible from Windows PCs than competing with Adobe for dollars from selling development tools for rich internet applications. This seems to be a better strategy to me. 

Disclaimer: The above post contains my own opinions and does not reflect the intentions, strategies, plans or thoughts of my employer