Netscape’s OpenID support is live. This release also greatly simplifies the signup process by removing the captcha and the request for other information that was previously required for registration.
The announcement just went public that, starting on Monday, Netscape.com and My.Netscape will support signup/signin via OpenID, and consequently, AOL screennames (AOL hosts an OpenID for each registered screenname). I’ve used the OpenID registration/signin process in our QA environment, and it is slick. Kudos to Blaine and Trey on this awesome new feature.
P.S. I know I’m biased, but I love it when a service delivers new features rather than just promising to get around to them.
My.Netscape: a website barely alive. Gentlemen, we can rebuild it. We have the technology. We have the capability to build the world’s best personalized homepage. My.Netscape will be that homepage. Better than it was before. Better, stronger, faster.
Our decision at Netscape to stop hosting the DTD for RSS 0.91 has inspired some healthy discussion around the Web on the topics of RSS and DTDs. Since I was speaking for Netscape in the official blog, I wanted to lay out my personal thoughts on the matter. However, as is normally the case, the main points I wanted to make have already been made in the Slashdot discussion.
And they can’t set up a redirect to the new hosting location?
What in the world would be the point? That would merely duplicate the problem to a different location. As was clearly stated in the article by Mr. Finke, four-million hits every day is a crapload of bandwidth wasted re-downloading a file that will never change. The RSS 0.91 spec is finished, complete, and yes, for all intents and purposes, written in stone. Stop looking at it every damned day. It will not change. Ever. It’s truly stupid for client-side software to be accessing it over the Internet to read its forever-static contents. That’s like checking the writings of a dead poet every day to see if anything’s changed.
And any dev who codes his app to check a file like this every day instead of caching it client-side should be smacked oh-my-god-so-frickin-hard.
I couldn’t have said it better myself, so I’m not going to try.
This is the perfect example of why a URI is not necessarily supposed to be treated as a URL. http://my.netscape.com/publish/formats/rss-0.91.dtd is just a unique identifier for the RSS DTD. It used to also be hosted there as a convenience, but your software isn’t supposed to rely on that.
Seriously though, Isn’t 0.91 dead anyway? Why not get on the 2.0 bandwagon? Is there still value in 0.91?
Exactly. What is there to gain by staying with 0.91 over 1.0 or 2.0? Most software companies have support life-cycles for their products; just think of this as Netscape sunsetting support for RSS 0.91.
According to this Slashdot post, my.netscape.com was hosting a DTD file critical for users of RSS 0.91 feeds, but when we closed My Netscape for a much needed redesign, the file got lost in the shuffle. (Why an RSS DTD file was being hosted under the my.netscape.com subdomain is anybody’s guess…)
We should have it available again fairly soon, but as it appears that this was noticed as early as Friday, I wish that someone had notified us about it before the middle of a three-day weekend, when making a change to a production site becomes much more time-consuming. (Actually, I wish that someone had notified us at all: as far as I know, nobody contacted anybody at Netscape to report the problem before it was reported on Slashdot.)